Re: [RFC] Custom Casting
| From: | Stas Malyshev | Date: | Mon, 14 May 2012 18:28:15 +0000 |
| Subject: | Re: [RFC] Custom Casting | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-60583@lists.php.net to get a copy of this message | ||
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