Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58313
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.52.25.107 as permitted sender) client-ip=10.52.25.107;
MIME-Version: 1.0
In-Reply-To: <CAAyV7nGOFuOHQxySb7D0iH4c3Kep9s=snNms-q-4fH4GN=ONog@mail.gmail.com>
References: <CAAyV7nGB3+5KfGNUr2yWUE8qx3y_Dz7EM1u+0pKra4LEqdEjJw@mail.gmail.com>
	<CABBJUpfEaa+Y+Qn6jFMfwemguq3C0=iCpCSfvrMSTouN=-tBFA@mail.gmail.com>
	<CAAyV7nFwwenp5m2G+n5VNnJbU4YC0303SEALMYQ0NaQ9A0hp9Q@mail.gmail.com>
	<6d4a9f99bc550c8c673b32cbccc52444.squirrel@www.l-i-e.com>
	<CAAyV7nEZNu9y0SCu=hAVroRdfQ=E9twChLujKQY-5GS0Yves-w@mail.gmail.com>
	<b2d9354fa7026d842129ffa1c1b68d8d.squirrel@www.l-i-e.com>
	<CAAyV7nFP6j0NCSNfO7X=Cb-hpFbb7tfUuOhnYP=4j2UJ+p8Ycg@mail.gmail.com>
	<CAAyV7nE_RQGiGOyu90d+y85i1VZkKXO3uSFVssFE9iHCJsqU9Q@mail.gmail.com>
	<29360b43e9c23389dac011c6a53332bc.squirrel@www.l-i-e.com>
	<CAAyV7nGOFuOHQxySb7D0iH4c3Kep9s=snNms-q-4fH4GN=ONog@mail.gmail.com>
Date: Tue, 28 Feb 2012 16:37:51 -0800
Message-ID: <CAKOpQSz0qZr0BhhAN357janmPnwMXs1Mbov75tt50Z6D642fkA@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Richard Lynch <ceo@l-i-e.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf307d0416b39fe804ba0f8d74
Subject: Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
From: kris.craig@gmail.com (Kris Craig)

--20cf307d0416b39fe804ba0f8d74
Content-Type: text/plain; charset=ISO-8859-1

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 <ircmaxell@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 <ceo@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
>
>

--20cf307d0416b39fe804ba0f8d74--