Stas, On Sat, Mar 3, 2012 at 9:27 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote:
>> https://wiki.php.net/rfc/object_cast_to_types > > Some notes: > > 1. Use cases for this are unclear. Wrapping scalar types does not seem very > efficient as conversion is always one-directional - once you do any > operation your type is gone, so unless you re-wrap it each time (at which > point you could as well un-wrap it manually) it's not very useful. > Enabling passing SplFixedArray to array functions is very simple - as with > any iterable type - just use iterator_to_array (if you don't have builtin > convertor, which SplFixedArray does). But it's not always a good idea - > since it creates a full copy. Both this method and your conversion do not > have a context so it is not possible to avoid creating a full copy. That's quite fair and understandable. And something I'm hoping people on the list here will be able to help out with. I know this is an often requested feature (and I've hit cases where "it would be nice if"). I just can't think of any good ones now. One thing to note is that this becomes much more useful if implemented along-side the other RFC I proposed with parameter casting ( https://wiki.php.net/rfc/parameter_type_casting_hints ). Another thing to consider (or, let me propose), is that consistency is a reason to add this. Right now, we can cast to string types and control the cast, but we can't to any other type. So this would open the ability for consistent casting across all scalar (non-object) types... > 2. Having separate methods is probably not the best idea. It may lead to > implementation having inconsistent conversions between types, such as floats > and integers, etc. or having conversions to float but not int and getting > very hard to debug errors because of that. Also may lead to conversion be > context-dependent and create very confusing results. Well, as you know that was part of my original proposal ( https://wiki.php.net/rfc/object_cast_magic ). However, after talking with a few core devs about it, it seemed that separate methods are the preferred solution, as the single method requires a big switch (which isn't as clean, and will promote returning improper types, Floats when an int was asked for, etc)... For that reason, it seems more fragile to maintain, so I agreed with splitting it to multiple methods. But either way, if people feel strongly, I would be willing to change the implementation... > 3. There's already cast_object handler, why not use it? I'm not sure messing > with get is a good idea, it's not exactly meant for that. cast_object goes to zend_cast_object_tostring(), which is specifically hard-coded to return specific values for types. So rather than edit that, I implemented a wrapper on-top to implement these additions. That way, the current (BC) functionality remains untouched... But I could see pushing this code into that handler. My only concern there is naming (it's called tostring, but it does far more than that)... As far as the get() handler, I can see the uses, but if it's really that big of an issue (not saying you're making it out to be), I think we can remove that part of the proposal without substantially affecting the concept of the patch and RFC... Thanks for the comments Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
