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).
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
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
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 CastingHello 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).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_scalarThank you in advance,
Seva LapshaHi 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
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 CastingHello 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).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_scalarThank you in advance,
Seva LapshaOn 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
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 CastingHello 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).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_scalarThank you in advance,
Seva LapshaOn 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
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 CastingSorry, 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 CastingHello 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).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_scalarThank you in advance,
Seva LapshaOn 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
How would one use your Castable interface to cast a Class "Test" to any of integer, array or boolean?
From: Seva Lapsha [mailto:seva.lapsha@gmail.com]
Sent: Monday, May 14, 2012 12:19 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Custom Casting
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.commailto:seva.lapsha@gmail.com]
Sent: Monday, May 14, 2012tel:2012 6:18 AM
To: Clint Priest
Cc: internals@lists.php.netmailto: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.commailto:seva.lapsha@gmail.com]
Sent: Wednesday, May 09, 2012tel:2012 4:56 PM
To: internals@lists.php.netmailto:internals@lists.php.net
Subject: [PHP-DEV] [RFC] Custom CastingHello 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).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_scalarThank you in advance,
Seva LapshaOn Wed, Apr 11, 2012tel:2012 at 6:14 PM, Yasuo Ohgaki <yohgaki@ohgaki.netmailto: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.netmailto:yohgaki@ohgaki.net--
To
unsubscribe,
visit: http://www.php.net/unsub.php
Please read my previous comment.
How would one use your Castable interface to cast a Class “Test” to any
of integer, array or boolean?****
From: Seva Lapsha [mailto:seva.lapsha@gmail.com]
Sent: Monday, May 14, 2012 12:19 PMTo: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Custom Casting****
My pastbin is for casting anything to anything.****
On Mon, May 14, 2012 at 11:24 AM, Clint Priest cpriest@zerocue.com
wrote:****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 CastingSorry, 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 CastingHello 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).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_scalarThank you in advance,
Seva LapshaOn 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
Hi!
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).
I think there's an issue with this idea. As far as I understand, what is
proposed is kind of cast-constructor paradigm. However, the result of
(ClassName)$var would be expected to be an object of type ClassName.
That is, however, not what cast() returns - it returns integer $var.
Since there's no way for foo(ClassName $var) to know where $var came
from, the result of $var = (ClassName)$var; is just a simple integer and
foo() would reject it since it's not an object of type ClassName.
Of course, you could just create this instead:
class PositiveInteger {
private $i;
function __construct($i) {
if(intval($i) < 1) $i = 1;
$this->i = $i;
}
function intval()
{
return $this->i;
}
}
function foo(PositiveInteger $i) { return 2*sqrt($i->intval()); }
and then:
foo(new PositiveInteger(42));
But this is doable right now, even if sounds a bit of overkill for me. I
wouldn't mind also having (int)$i done with some magic methods, as
proposed in RFCs you mentioned.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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".
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);
}
Hope this makes sense.
On Sun, May 13, 2012 at 7:40 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
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).I think there's an issue with this idea. As far as I understand, what is
proposed is kind of cast-constructor paradigm. However, the result of
(ClassName)$var would be expected to be an object of type ClassName.
That is, however, not what cast() returns - it returns integer $var.
Since there's no way for foo(ClassName $var) to know where $var came
from, the result of $var = (ClassName)$var; is just a simple integer and
foo() would reject it since it's not an object of type ClassName.Of course, you could just create this instead:
class PositiveInteger {
private $i;
function __construct($i) {
if(intval($i) < 1) $i = 1;
$this->i = $i;
}
functionintval()
{
return $this->i;
}
}function foo(PositiveInteger $i) { return 2*sqrt($i->intval()); }
and then:
foo(new PositiveInteger(42));
But this is doable right now, even if sounds a bit of overkill for me. I
wouldn't mind also having (int)$i done with some magic methods, as
proposed in RFCs you mentioned.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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
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