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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
