[RFC] Custom Casting View as Markdown

My pastbin is for casting anything to anything.

Both of the RFC's you reference are for casting TO a scalar, not TO an
object type. Your pastbin is for casting FROM a scalar TO an object.

-----Original Message-----
From: Seva Lapsha [mailto:seva.lapsha@gmail.com]
Sent: Monday, May 14, 2012 6:18 AM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Custom Casting

Sorry, I comprehend neither the cause nor the effect in your argument
statement. Can you please elaborate?

This has already been covered quite a bit, the problem with your
suggestion is that the compiler needs to determine the type it is cast
to, which is why the __toInt(), __toArray(), etc, so that the language
can request the type it needs to cast to.

-----Original Message-----
From: Seva Lapsha [mailto:seva.lapsha@gmail.com]
Sent: Wednesday, May 09, 2012 4:56 PM
To: internals@lists.php.net
Subject: [PHP-DEV] [RFC] Custom Casting

Hello All,

Please be kind to review and comment my proposal for custom casting
in
PHP (or let me know if a similar proposal was already
discussed).

http://pastebin.com/sPb0i8U6

IMHO, it's more simple and on the other hand more flexible than
proposed
in:

https://wiki.php.net/rfc/object_cast_to_types
https://wiki.php.net/rfc/class_casting_to_scalar

Thank you in advance,
Seva Lapsha

On Wed, Apr 11, 2012 at 6:14 PM, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:

Hi all,

I think my RFC confused people on this list due to improper
descriptions and too much information. Sorry for the confusion. I
revised the RFC so that most important points can be understood at
a
glance.

https://wiki.php.net/rfc/nophptags

Please read again if you've read already and give comments.
Thank you.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--
To
unsubscribe,
visit: http://www.php.net/unsub.php

Thanks.

On Mon, May 14, 2012 at 2:28 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:

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 2sqrt($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