[RFC - discussion] Object Scalar Type Casting Magic Methods

Stas,

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