Thanks.
On Mon, May 14, 2012 at 2:28 PM, Stas Malyshev <smalys...@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
>
