Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60583
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.143 as permitted sender)
Message-ID: <4FB14EBF.7070404@sugarcrm.com>
Date: Mon, 14 May 2012 11:28:15 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Seva Lapsha <seva.lapsha@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAOtCo3rn=XqaFn+ZGOV-0Az_pOVik4eBhNesXmHgU_d3WsyZZw@mail.gmail.com> <4FB04675.6000307@sugarcrm.com> <CAOtCo3rWwFuZ8Bo+8L+gR+gdKz9X53aPUAT=ike48oKDuTfDpQ@mail.gmail.com>
In-Reply-To: <CAOtCo3rWwFuZ8Bo+8L+gR+gdKz9X53aPUAT=ike48oKDuTfDpQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Custom Casting
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> Not quite. The proposed is a syntactic sugar which is thought to handle
> any transformation of a value, not necessarily or limited to type or
> class conversion. It is of course possible to limit the usage to just
> that, with any user defined convention or "best practice". In fact it's
> pretty distinct from primitive casting, I just had in mind that reusing
> the casting syntax could be an advantage due to similarity of the behavior.
> 
> In simple words the statements of /$var = (ClassName)$var/ or
> /function(ClassName $var){}/ would not be read as "Cast to", but "Cast
> with".

But currently this syntax already means "convert value to a value of
this type" in the first case and "allow only value of this type" in the
second case. Overloading this syntax IMHO will lead to a singificant
confusion, and you would not know what exactly foo(ClassName $var) means
- would it only accept ClassName or would it instead convert $var using
transformation ClassName?
My point is exactly that these are different things with different results.

> The example suggestion with wrapping the value in an object just for
> handling value validation/sanitization is not just overkill, but also is
> excess, since there is no any need to have the value wrapped after the
> function input processing. In fact, the closest construct to the
> mentioned is:
> 
> function foo(/* to be casted with PositiveInteger */ $i) {
>     $i = PositiveInteger::cast($i);
>     return 2*sqrt($i);
> }

Yes, I know. These are two different approaches - the difference is
where the casting responsibility lies. You can define a type
PositiveInteger and assign it the responsibility or you can define that
each client is responsible for its own casting, however it wants to do
it. I understood that you were going for the former.

I think the idea of custom casting might be useful, but overloading
existing syntax with it will lead to serious confusion.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227