Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58232
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
Received-SPF: pass (google.com: domain of julienpauli@gmail.com designates 10.14.99.2 as permitted sender) client-ip=10.14.99.2;
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAAyV7nE_RQGiGOyu90d+y85i1VZkKXO3uSFVssFE9iHCJsqU9Q@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>
Date: Tue, 28 Feb 2012 11:54:12 +0100
Message-ID: <CAMUwpuRf5PJQivZjsY4QmcynGVJe==AHNLF4PLzcZG4=0KFCwQ@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=bcaec52be49388457c04ba040eb8
Subject: Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
From: jpauli@php.net (jpauli)

--bcaec52be49388457c04ba040eb8
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 28, 2012 at 6:05 AM, Anthony Ferrara <ircmaxell@gmail.com>wrote:

> Ok, I've made a proof-of-concept patch here:
> https://gist.github.com/1929587
>
> Note that there are still a few memory leaks in there that would need
> to be cleaned up, but I just wanted to make a really quick POC before
> cleaning anything up to make it worthy of addition...
>
> One could use zend_get_type_by_const() for help :)

Another patch would need to be made for the __castFrom($value)
> implementation, but I think we'll split that off into another
> topic/RFC since that's quite a bit more work than this is...
>
> What are your thoughts?
>

Anyway... I like but the changes would really need some documentation.
And before that, we would need several RFC (one per concept seems to be a
good idea).



>
> It adds 2 new magic methods: __castTo($type) and __assign($value):
>
> __castTo($type) is called by the cast_object handler, and the get
> handler.  The cast_object handler will pass in the requested type as a
> string (NULL, boolean, integer, double, string, array, object,
> resource, callable).  Note that it does not check the return type (yet
> at least).  The get handler will pass in "native" as $type.  So that's
> used by combination operators (+=, +=, etc).
>
> __assign($value) is called by the set handler.  This gets called
> anytime the object is assigned to.  To allow for conditional
> assignment, if you return false from the handler, the value overwrites
> the zval (to allow for destructing of the object and not overriding
> assignment, if you want)...
>
> So, with this script:
>
> <?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++;
> var_dump($a); // int(1) - Normal type casting rules apply here.
> $b++;
> var_dump($b); // object, value = 2, increment captured
>
> $a = new Foo;
> $b = new Bar;
> $a = 3;
> $b = 3;
> var_dump($a); // int(3) - Normal rules apply
> var_dump($b); // object, value = 3, assignment captured
>
> $a = new Foo;
> $b = new Bar;
> $a = 10;
> $b = 10;
> var_dump($a); // int(10) - Normal rules apply
> var_dump($b); // int(10) - False was returned, so normal assignment happens
>
>
> Now, for some casting:
> $a = new Foo;
> $b = new Bar;
> $a->value = 100;
> $b->value = 100;
> var_dump((int) $a); // int(1) - Normal type casting rules apply
> var_dump((int) $b); // int(100) - Cast was captured
>
> $a = new Foo;
> $b = new Bar;
> $a->value = 2;
> $b->value = 2;
> var_dump(substr("test", $a)); // string(1) "t"
> var_dump(substr("test", $b)); // string(1) "te"
>
> Anthony
>

Sorry for repeating, but why not RFC that ?

Julien.P


>
> On Mon, Feb 27, 2012 at 3:24 PM, Anthony Ferrara <ircmaxell@gmail.com>
> wrote:
> > Rich,
> >
> > I appreciate the candid and honest nature of your reply, while
> > maintaining civility.  This list needs more of that. Further replies
> > inline:
> >
> > On Mon, Feb 27, 2012 at 1:54 PM, Richard Lynch <ceo@l-i-e.com> wrote:
> >> On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote:
> >>>> I have to say that no matter how much a luv my OOP, turning every
> >>>> built-in type into an Object is just a Bad Idea...
> >>>>
> >>>> It's a form of bloat on RAM and CPU with minimal added value, imho.
> >>
> >>> Re-read what I had written.  I never said to turn every built-in type
> >>> into an object.  In fact, what I was talking about was keeping and
> >>> preserving the base types as-is.  All that I was proposing was adding
> >>> the ability to cast from and to the primitives.  That way you could
> >>> silently convert back and forth as needed (transparently when
> >>> possible).
> >>>
> >>
> >> I apologize that my brevity has been misconstrued.
> >>
> >> You are certainly free, even with the tools available in PHP, to
> >> "wrap" an object around integers, strings, and so on.
> >>
> >> There may even be occasions where I think that would be a Good Idea
> (tm).
> >
> > Well, you can kind of do it now.  You can't directly operate on those
> > objects.  You need to first manually cast them back to the native
> > type.  Take a look at SplFixedArray (
> > http://www.php.net/manual/en/class.splfixedarray.php ).  It has a pair
> > of methods, a static fromArray(), and a instance toArray().  What I'm
> > talking about is adding the ability to push these conversions down to
> > the engine level.
> >
> >> What I object to is building such a facility into core PHP, because:
> >>
> >> 1) You can already do it in userland, and I believe that's where it
> >> belongs.
> >
> > Actually, almost exactly the opposite.  You can't do it in userland,
> > but you can in a PECL extension (via cast_object(), get() and set()).
> > The first part of this proposal is basically just exposing those
> > methods (almost 1:1, only consolidating cast_object and get into a
> > single method with a parameter defining the difference).
> >
> >> 2) It unnecessarily [see 1] complicates core PHP, whose major
> >> strengths that drive its success includes its simplicity.
> >
> > Actually, the first part of the proposal doesn't really change the
> > core that much.  All it does is add standard object handlers to expose
> > cast_object (which is already partially exposed via __toString), get
> > and set (which are currently null).  There shouldn't really be other
> > changes required to the core for the first part at least.
> >
> > The second part of the proposal (the castFrom auto-casting) would
> > require some more changes to the core, and be much more significant.
> > To be honest, I think that would be a separate effort (and a separate
> > RFC) the more I think about it.
> >
> >>>> No matter which way you twist this pretzel:
> >>
> >> I had hoped that this bit would hint that all the proposals along
> >> these lines, including yours, are proposals I would vote against, even
> >> though I did over-blow your actual proposal.
> >>
> >>>> -1
> >>
> >>> So what it sounds like you're -1ing to, is not actually what was
> >>> proposed...
> >>>
> >>> I'm starting to work on a patch for this as a proof of concept...
> >>
> >> Please do so!
> >>
> >> I'll still vote -1, but obviously others will vote as they see fit.
> >>
> >> All these ideas are welcome.  The ones with complete patches even more
> >> so, as they allow a true idea of what the change would mean.
> >>
> >> Unfortunately, however, I must repeat that, so far, the idea has
> >> always fallen flat on its face when the proposer actually attempts to
> >> put action into deed, making a patch that fully meets their proposal.
> >>
> >> That doesn't mean you can't succeed, if you are more skilled than all
> >> your predecessors.
> >
> > I don't think skill has that much to do with it.  I think the real key
> > difference is what's being attempted...
> >
> > Anthony
> >
> >> --
> >> 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
>
>

--bcaec52be49388457c04ba040eb8--