Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60585
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FB14EBF.7070404@sugarcrm.com>
References: <CAOtCo3rn=XqaFn+ZGOV-0Az_pOVik4eBhNesXmHgU_d3WsyZZw@mail.gmail.com>
	<4FB04675.6000307@sugarcrm.com>
	<CAOtCo3rWwFuZ8Bo+8L+gR+gdKz9X53aPUAT=ike48oKDuTfDpQ@mail.gmail.com>
	<4FB14EBF.7070404@sugarcrm.com>
Date: Mon, 14 May 2012 14:44:18 -0400
Message-ID: <CAOtCo3rbR+hDy=Vx-HBNhN06UZk7AmVEYTpwV=+5FWzdrp63Hw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8f6465f538ec1504c003798f
Subject: Re: [PHP-DEV] [RFC] Custom Casting
From: seva.lapsha@gmail.com (Seva Lapsha)

--e89a8f6465f538ec1504c003798f
Content-Type: text/plain; charset=ISO-8859-1

Thanks.

On Mon, May 14, 2012 at 2:28 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> 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
>

--e89a8f6465f538ec1504c003798f--