At 03:02 18/02/2006, Marcus Boerger wrote:
the point is not being able to treat them differently. The point is being
able to distinguish them so the right operation is called.
Erm sorry, but it's exactly the same :)
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
Hello Zeev and hello Sara
Saturday, February 18, 2006, 1:04:20 AM, you wrote:
> At 01:24 18/02/2006, Marcus Boerger wrote:
>>Actually Sara only asked whether she could add a flag to some handlers.
>>That has nothing to with anything you started to discuss from there.
> Uhm, Sara asked whether sh
At 01:24 18/02/2006, Marcus Boerger wrote:
Actually Sara only asked whether she could add a flag to some handlers.
That has nothing to with anything you started to discuss from there.
Uhm, Sara asked whether she could add a flag to a specific operator
to facilitate a certain behavior, namely,
Hello Zeev,
Friday, February 17, 2006, 12:09:26 PM, you wrote:
> At 11:55 17/02/2006, Stefan Walk wrote:
>>On 16/02/06, Zeev Suraski <[EMAIL PROTECTED]> wrote:
>> > In languages where operator overloading is supported, it comes hand
>> > in hand with strict typing, which wouldn't allow for differ
Interesting stuff! Exactly the kind of stuff that's worrying me.
I think you found a conceptual bug in zend_hash_compare(), I think
it's worth fixing.
Zeev
At 14:59 17/02/2006, Jakub Vrana wrote:
Sara Golemon wrote:
> Yes, and that's the problem. $a > $b *isn't* read by the
current parse
Jakub Vrana wrote:
Sara Golemon wrote:
with thanks to Sara! - because (not for the first time) your post
allowed me to learn/understand some new stuff. (Sara seems to
have a knack for explaining stuff in a way that dummies can [also]
understand it - that a good thing[tm]!)
Yes, and that's t
Sara Golemon wrote:
> Yes, and that's the problem. $a > $b *isn't* read by the current parser as
> $a > $b, it's read as $b < $a.
> For all normal PHP comparisons, the distinction is unimportant... 4 < 2
> and 2 > 4 will both evaluate to false after all.
Array comparison is due this logic also
At 11:55 17/02/2006, Stefan Walk wrote:
On 16/02/06, Zeev Suraski <[EMAIL PROTECTED]> wrote:
> In languages where operator overloading is supported, it comes hand
> in hand with strict typing, which wouldn't allow for different values
> for x>y and y
> Zeev
That's not true, Ruby for example has
On 16/02/06, Zeev Suraski <[EMAIL PROTECTED]> wrote:
> In languages where operator overloading is supported, it comes hand
> in hand with strict typing, which wouldn't allow for different values
> for x>y and y
> Zeev
That's not true, Ruby for example has operator overloading, and has no
problems
At 00:39 17/02/2006, Sara Golemon wrote:
I gave this some thought as I was designing the overloading approach. I
didn't go there because I actually wanted to allow asymmetry between the
operands as sometimes communative properties don't apply cleanly. Most
obviously in the case of sub/div ops, b
At 02:39 PM 2/16/2006, Sara Golemon wrote:
I gave this some thought as I was designing the overloading approach. I
didn't go there because I actually wanted to allow asymmetry between the
operands as sometimes communative properties don't apply cleanly. Most
obviously in the case of sub/div ops,
Just thought I'd chime in here with an example that seemed relevant:
cout << "foo" << "bar" << endl;
cin >> input;
Here, << and >> have nothing to do with bit-shifting and have different
meanings. So, maybe one can't assume that '<' and '>' always have to apply
to the typical mathematical ope
> Here, << and >> have nothing to do with bit-shifting and have different
> meanings. So, maybe one can't assume that '<' and '>' always have to
apply
> to the typical mathematical operations (e.g. $pacman < $ghost).
>
That's one reason (one which lends credibility to the overloading kills
readabi
I understand. Aren't you slightly worried about the implications of
making it possible for x>y to have a different meaning than y
In languages where operator overloading is supported, it comes hand
in hand with strict typing, which wouldn't allow for different values
for x>y and y
Zeev
At 19
>
> I am not a big fan of operator overloading because after years of C++
> development I came to the conclusion that the syntactic sugar it
> provided was not worth the debugging hours lost due to hidden magic
> happening. It actually makes it hard to understand certain code when
> you're just re
I am not a big fan of operator overloading because after years of C++
development I came to the conclusion that the syntactic sugar it
provided was not worth the debugging hours lost due to hidden magic
happening. It actually makes it hard to understand certain code when
you're just reading i
> >Enter PECL/operator, which tries to implement operator overloading
> >for objects (and does a decent job at that). In the interrest of
> >ease of use and consistency, every overloaded binary operator is
> >[meant to be] left associative. This is, in the expression expr1
> >op expr2 expr1 g
At 19:23 16/02/2006, Sara Golemon wrote:
Hi, purely selfish request here, I'd like to make a minor change to
the parser... Just a bitty one... You won't even feel it...
Currently, when the parser encounters: expr1 > expr2 it quietly
(and reasonably) switches it around to expr2 < expr1 so th
18 matches
Mail list logo
