I think this is +1 for moving the conversation to a less crowded location.
Sorry guys I know I keep promising to take care of it but I've been swamped
all day. I'll try to find some time though.
--Kris
On Tue, Feb 28, 2012 at 4:28 PM, Anthony Ferrara <ircmax...@gmail.com>wrote:
> 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
>
>
