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...
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?
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
On Mon, Feb 27, 2012 at 3:24 PM, Anthony Ferrara <ircmax...@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 <c...@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
