Richard,
This is not overloading addition. Not by a long shot.
This is overloading casting to primitives (which happens in the case
of addition, but a bunch of others). It turns out that the addition
operator calls object->get in C to get the primitive value of the
object if it exists. That's where this works. So:
> This obviously trivial example makes perfect sense, until you realize
> that some moron (and PHP has lots of them) will sooner or later make
> ++ do something completely weird, and I'm going to have to edit their
> code-base and will have to dig through umpteen class files to figure
> out what the heck ++ means...
Yes, the example is trivial. And yes, it can be abused. But I think
you're blowing it WAY out of proportion. ++ still means what it
always has meant. It's the *exact* same as normal (addition is still
happening).
The only change is where the addition gets its value, and where that
value is stored.
And it's not really digging through umpteen classes to figure out what
the cast is. To be honest, you could say the exact same thing about
polymorphism. And the indirection there is actually seen as a *good*
thing. So I'm not sure what argument you're trying to make aside from
that you don't like it...
> And then god knows what happens when you do:
>
> $foo = new Foo(); //from library A
> $bar = new Bar(); //from library B
> $foobar = $foo + $bar;
> //Will this last statement even make sense, even though both Foo and
> Bar override the + operator, just in entirely different ways...
Neither override anything. let me say this again: THIS IS NOT DOING
OPERATOR OVERLOADING.
That's 100% predictable. Lookup Foo and Bar, and see if either/both
implement __castTo. If so, the types they return will tell you
exactly what it will be.
> How can you even guarantee that $foo, presumably taking precedence,
> won't attempt to access a non-existent property of Bar, generating an
> ignored E_NOTICE on most hosts, and introduce a subtle bug that nobody
> notices for months, even years, in a seldom-used function?
You don't need to. Because $foo will never know about $bar (or vise versa)...
And to be honest, you could say the same thing about LOTS of existing
NON-MAGIC functionality. So I don't see that this contributes to the
conversation at all...
> Your proposal lets one re-define + to mean whatever one wants, and
> while you might not abuse that, somebody else will...
Ok, This is rediculous. Open the patch. Tell me where it redefines
+, or even remotely can be used to... + is still a scalar operator,
and with this patch you cannot change that. The only thing this patch
lets you do with respect to the + operator is choose what the scalar
representation of the object is...
Personal Note:
I appreciate replies and concerns. But at least read the patch and
try to understand what the POC does before going off on a rant that
does nothing but turn people off unless you actually realize what's
going on. If you don't understand what it does, then ask. But don't
complain about things the feature doesn't even touch, it's
disrespectful and doesn't accomplish anything but to add noise to the
conversation.
Anthony
On Tue, Feb 28, 2012 at 4:37 PM, Richard Lynch <c...@l-i-e.com> wrote:
> On Mon, February 27, 2012 11:05 pm, Anthony Ferrara wrote:
>> <?php
>> class Foo {
>> public $value = 1;
>> }
>> class Bar {
>> public $value = 1;
>> public function __castTo($type) {
>> return $this->value;
>> }
>> public function __assign($value) {
>> $this->value = $value;
>> return $value != 10;
>> }
>> }
>>
>> $a = new Foo;
>> $b = new Bar;
>> $a++;
>
> So, here's the thing...
>
> This obviously trivial example makes perfect sense, until you realize
> that some moron (and PHP has lots of them) will sooner or later make
> ++ do something completely weird, and I'm going to have to edit their
> code-base and will have to dig through umpteen class files to figure
> out what the heck ++ means...
>
> I can see a lot of legitimate serious coders using this wisely.
>
> Unfortunately, I can see a million scripters using it very un-wisely.
>
> I can even see people overloading the plus operator for an object
> wrapped around an array in multiple different ways, then pulling in
> different libraries that seem quite useful, and the only way I can
> figure out what "+" means is to dig through even more files and figure
> out which bastard child this object comes from, that was passed into
> some random function that uses + on it.
>
> And then god knows what happens when you do:
>
> $foo = new Foo(); //from library A
> $bar = new Bar(); //from library B
> $foobar = $foo + $bar;
> //Will this last statement even make sense, even though both Foo and
> Bar override the + operator, just in entirely different ways...
>
> How can you even guarantee that $foo, presumably taking precedence,
> won't attempt to access a non-existent property of Bar, generating an
> ignored E_NOTICE on most hosts, and introduce a subtle bug that nobody
> notices for months, even years, in a seldom-used function?
>
> Consider the trivial example where Foo uses array_sum() and Bar uses
> count() comes up with a number. It's a totally meaningless number in
> any real-world scenario. How would one detect this bug, really, in
> some mish-mash of libraries from PEAR/PECL/homebrew-MVC/Framework.
>
> I'm sure you can define the "rules" in a page or so for precedence in
> type-casting and what happens when.
>
> But I really am not interested in figuring out the "rules" for + when
> I've been using it the same way since 2nd grade, with modest changes
> over the years that follow the spirit of "+"
>
> Your proposal lets one re-define + to mean whatever one wants, and
> while you might not abuse that, somebody else will...
>
> You might as well install runkit on everybody's server and let them
> have at it. :-)
>
> PHP was founded on the KISS principle, so that newbies can, in fact,
> write sub-optimal but working code quickly to get a website up, and to
> keep newbie fingers out of mashing gears.
>
> This is way over-the-top from that principle.
>
> --
> brain cancer update:
> http://richardlynch.blogspot.com/search/label/brain%20tumor
> Donate:
> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
