Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58559
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
Received-SPF: pass (google.com: domain of ircmaxell@gmail.com designates 10.224.207.70 as permitted sender) client-ip=10.224.207.70;
MIME-Version: 1.0
In-Reply-To: <4F52D301.5060101@sugarcrm.com>
References: <CAAyV7nHJWJDU=bkYHUOKs-WoYvPRq-G1Fs5mGD2=5A4bv5MPYg@mail.gmail.com>
	<4F52D301.5060101@sugarcrm.com>
Date: Sat, 3 Mar 2012 21:38:01 -0500
Message-ID: <CAAyV7nF2yiTRNH2-sh91PbD8JkgH51T0tG1VyqJzt+uTJw=ouQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC - discussion] Object Scalar Type Casting Magic Methods
From: ircmaxell@gmail.com (Anthony Ferrara)

Stas,

On Sat, Mar 3, 2012 at 9:27 PM, Stas Malyshev <smalyshev@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