Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86271
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.52 as permitted sender)
Message-ID: <5557B32E.70804@gmail.com>
Date: Sat, 16 May 2015 14:14:22 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Christoph Becker <cmbecker69@gmx.de>, 
 Guido Contreras Woda <guiwoda@gmail.com>,
 internals@lists.php.net
References: <CAGSCP-nS+f5p-n-KbVZ6mFEax8Mh50px2vBVjq96iPbgHva8WA@mail.gmail.com> <5553E139.8090805@gmx.de>
In-Reply-To: <5553E139.8090805@gmx.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Proposal: interfaces for object to scalar type
 casting
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> One of the biggest problems is that it's not always clear which
> conversion should be used; consider, for instance,
> 
>   $obj1 + $obj2
> 
> where __toInt() as well as __toFloat() might make sense.

If both are object, I would rather not use either conversion, I'd use
operator support instead, if operator is not supported by the objects
(or the objects do not have same operator handler) then all bets are
off. I guess we could keep them converted to int as they are now, but
it'd be something of "we must return something so we choose arbitrarily
and hope it's what you meant" than something with a robust semantics.
Primarily because for arbitrary objects there's really no semantics that
is natural here.

> A possible solution would be to force the conversion with type casts,
> but I don't see a real advantage in using
> 
>   (int) $obj1
> 
> over
> 
>   $obj1->toInt()

One advantage is that the former also accepts $obj1 being actual int.
Whether it's useful or not depends on the surrounding code of course.

> Another problem is that such automatic casting from objects to scalars
> might obscure the code.

True. I think this is one of the main reasons why it wasn't implemented.
-- 
Stas Malyshev
smalyshev@gmail.com