# [RFC] Custom Casting - Thread: https://externals.io/message/60523 - Original archive: https://news-web.php.net/php.internals/60523 - Started by Seva Lapsha on 2012-05-09T21:56:00+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #60523 — Seva Lapsha — 2012-05-09T21:56:00+00:00 URL: https://externals.io/message/60523#60523 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 > 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 --- ## #60556 — Clint Priest — 2012-05-13T23:27:25+00:00 URL: https://externals.io/message/60523#60556 · In reply to: #60523 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 > > > > > […] --- ## #60558 — Stas Malyshev — 2012-05-13T23:40:37+00:00 URL: https://externals.io/message/60523#60558 · In reply to: #60523 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). > > http://pastebin.com/sPb0i8U6 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 --- ## #60572 — Seva Lapsha — 2012-05-14T11:17:40+00:00 URL: https://externals.io/message/60523#60572 · In reply to: #60556 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. > > > […] > PHP (or let me know if a similar proposal was already > > […] > in: > > […] > wrote: > > […] > glance. > > […] --- ## #60576 — Seva Lapsha — 2012-05-14T11:44:56+00:00 URL: https://externals.io/message/60523#60576 · In reply to: #60558 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 2*sqrt($i); } Hope this makes sense. On Sun, May 13, 2012 at 7:40 PM, Stas Malyshev wrote: > Hi! > > > […] > PHP > > […] > > 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 --- ## #60581 — Clint Priest — 2012-05-14T15:24:35+00:00 URL: https://externals.io/message/60523#60581 · In reply to: #60572 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. > > > […] > PHP (or let me know if a similar proposal was already > > […] > in: > > […] > wrote: > > […] > glance. > > […] --- ## #60582 — Seva Lapsha — 2012-05-14T17:19:20+00:00 URL: https://externals.io/message/60523#60582 · In reply to: #60581 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? > > > > > […] --- ## #60583 — Stas Malyshev — 2012-05-14T18:28:15+00:00 URL: https://externals.io/message/60523#60583 · In reply to: #60576 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 --- ## #60585 — Seva Lapsha — 2012-05-14T18:44:18+00:00 URL: https://externals.io/message/60523#60585 · In reply to: #60583 Thanks. On Mon, May 14, 2012 at 2:28 PM, Stas Malyshev wrote: > Hi! > > > […] > behavior. > > […] > > 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. > > > […] > > 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 --- ## #60587 — Clint Priest — 2012-05-14T19:31:50+00:00 URL: https://externals.io/message/60523#60587 · In reply to: #60582 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.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. > > > […] > PHP (or let me know if a similar proposal was already > > […] > in: > > […] > wrote: > > […] > glance. > > […] --- ## #60588 — Seva Lapsha — 2012-05-15T01:17:10+00:00 URL: https://externals.io/message/60523#60588 · In reply to: #60587 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 PM > > *To:* 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 > 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 Casting > > Sorry, I comprehend neither the cause nor the effect in your argument > statement. Can you please elaborate? > > > > > […] > > ** **