What about a magic __toArray() method?

  108351
February 4, 2020 07:15 mtkocak@gmail.com (=?UTF-8?Q?Midori_Ko=C3=A7ak?=)
As you know we have __toString method that runs whenever an object is
typecasted to string or it is directly echoed.

'value'
    ];
  }
});


$casted = (array)$class;
print_r($casted);

/*
prints:
Array
(
    [key] => value
)
mahmut
*/

What would you think? I think it would add value.
  108352
February 4, 2020 07:18 mtkocak@gmail.com (=?UTF-8?Q?Midori_Ko=C3=A7ak?=)
Or we can deprecate __toString() method at all and detect cast events
instead. Would it make more sense? Something like this __casted().

P.S: I saw the previous conversation but hence now we have types, it would
make sense.

Midori

On Tue, 4 Feb 2020 at 08:15, Midori Koçak <mtkocak@gmail.com> wrote:

> As you know we have __toString method that runs whenever an object is > typecasted to string or it is directly echoed. > > > $class = (new class{ > public function __toString(){ > echo "casted\n"; > return "mahmut\n"; > } > }); > > echo $class; > $casted = (string)$class; > > /* > prints: > casted > mahmut > casted > mahmut > */ > > > As you know toArray() method implemented when an object is converted into > and array and most of the time when a plain data object is sent to > front-end. > > Having a magic method like __toString called __toArray would be useful to > detect and act on conversion events. > > Roughly it would be like: > > > $class = (new class{ > public function __toArray(){ > echo "casted\n"; > return > [ > 'key'=>'value' > ]; > } > }); > > > $casted = (array)$class; > print_r($casted); > > /* > prints: > Array > ( > [key] => value > ) > mahmut > */ > > What would you think? I think it would add value. >
  108354
February 4, 2020 07:25 mtkocak@gmail.com (=?UTF-8?Q?Midori_Ko=C3=A7ak?=)
Oh there is even a rfc. https://wiki.php.net/rfc/to-array What is the
status of this?

On Tue, 4 Feb 2020 at 08:18, Midori Koçak <mtkocak@gmail.com> wrote:

> Or we can deprecate __toString() method at all and detect cast events > instead. Would it make more sense? Something like this __casted(). > > P.S: I saw the previous conversation but hence now we have types, it would > make sense. > > Midori > > On Tue, 4 Feb 2020 at 08:15, Midori Koçak <mtkocak@gmail.com> wrote: > >> As you know we have __toString method that runs whenever an object is >> typecasted to string or it is directly echoed. >> >> > >> $class = (new class{ >> public function __toString(){ >> echo "casted\n"; >> return "mahmut\n"; >> } >> }); >> >> echo $class; >> $casted = (string)$class; >> >> /* >> prints: >> casted >> mahmut >> casted >> mahmut >> */ >> >> >> As you know toArray() method implemented when an object is converted into >> and array and most of the time when a plain data object is sent to >> front-end. >> >> Having a magic method like __toString called __toArray would be useful to >> detect and act on conversion events. >> >> Roughly it would be like: >> >> > >> $class = (new class{ >> public function __toArray(){ >> echo "casted\n"; >> return >> [ >> 'key'=>'value' >> ]; >> } >> }); >> >> >> $casted = (array)$class; >> print_r($casted); >> >> /* >> prints: >> Array >> ( >> [key] => value >> ) >> mahmut >> */ >> >> What would you think? I think it would add value. >> >
  108365
February 4, 2020 12:39 stevenwadejr@gmail.com (Steven Wade)
> Oh there is even a rfc. https://wiki.php.net/rfc/to-array What is the > status of this?
Hi there, I’m the author of that RFC. I intend to post it officially for discussion soon, I’ve just been busy and haven’t had the time that would be needed to respond to the discussion emails when they came in.
  108373
February 4, 2020 13:26 stevenwadejr@gmail.com (Steven Wade)
> Oh there is even a rfc. https://wiki.php.net/rfc/to-array What is the > status of this?
This RFC has now been moved to “under discussion” with the discussion happening here: https://externals.io/message/108369 <https://externals.io/message/108369>
  108355
February 4, 2020 07:26 andreas@heigl.org (Andreas Heigl)
--TSkUG3VnoW9jEYRaKUJRKeKwYfedd3bAh
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Hey all.

Instead of adding more magic I personally like the approach of
explicitness more and your suggest adding an interface "Arrayable"
(naming is hard and this might not be the best name) instead. Whether
that interface then defines a `__toArray()`-method or something entirely
different is then a different matter.

Additionally this would be in line with Nicolas RFC regarding
"Stringable" (https://wiki.php.net/rfc/stringable)

Just my 0.02=E2=82=AC

Cheers

Andreas

Am 04.02.20 um 08:18 schrieb Midori Ko=C3=A7ak:
> Or we can deprecate __toString() method at all and detect cast events > instead. Would it make more sense? Something like this __casted(). >=20 > P.S: I saw the previous conversation but hence now we have types, it wo= uld
> make sense. >=20 > Midori >=20 > On Tue, 4 Feb 2020 at 08:15, Midori Ko=C3=A7ak <mtkocak@gmail.com> wrot= e:
>=20 >> As you know we have __toString method that runs whenever an object is >> typecasted to string or it is directly echoed. >> >> > >> $class =3D (new class{ >> public function __toString(){ >> echo "casted\n"; >> return "mahmut\n"; >> } >> }); >> >> echo $class; >> $casted =3D (string)$class; >> >> /* >> prints: >> casted >> mahmut >> casted >> mahmut >> */ >> >> >> As you know toArray() method implemented when an object is converted i= nto
>> and array and most of the time when a plain data object is sent to >> front-end. >> >> Having a magic method like __toString called __toArray would be useful= to
>> detect and act on conversion events. >> >> Roughly it would be like: >> >> > >> $class =3D (new class{ >> public function __toArray(){ >> echo "casted\n"; >> return >> [ >> 'key'=3D>'value' >> ]; >> } >> }); >> >> >> $casted =3D (array)$class; >> print_r($casted); >> >> /* >> prints: >> Array >> ( >> [key] =3D> value >> ) >> mahmut >> */ >> >> What would you think? I think it would add value. >> >=20
--=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +---------------------------------------------------------------------+ | http://hei.gl/root-ca | +---------------------------------------------------------------------+ --TSkUG3VnoW9jEYRaKUJRKeKwYfedd3bAh--
  108358
February 4, 2020 10:30 ocramius@gmail.com (Marco Pivetta)
Hey Midori,

This has been discussed in more depth 2 years ago:
https://externals.io/message/98539#98539

In practice, the `(array)` cast is one of the few operations that don't
cause observable side-effects in this programming language: let's please
keep it as such.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On Tue, Feb 4, 2020 at 8:15 AM Midori Koçak <mtkocak@gmail.com> wrote:

> As you know we have __toString method that runs whenever an object is > typecasted to string or it is directly echoed. > > > $class = (new class{ > public function __toString(){ > echo "casted\n"; > return "mahmut\n"; > } > }); > > echo $class; > $casted = (string)$class; > > /* > prints: > casted > mahmut > casted > mahmut > */ > > > As you know toArray() method implemented when an object is converted into > and array and most of the time when a plain data object is sent to > front-end. > > Having a magic method like __toString called __toArray would be useful to > detect and act on conversion events. > > Roughly it would be like: > > > $class = (new class{ > public function __toArray(){ > echo "casted\n"; > return > [ > 'key'=>'value' > ]; > } > }); > > > $casted = (array)$class; > print_r($casted); > > /* > prints: > Array > ( > [key] => value > ) > mahmut > */ > > What would you think? I think it would add value. >
  108360
February 4, 2020 10:35 mtkocak@gmail.com (=?UTF-8?Q?Midori_Ko=C3=A7ak?=)
Marco, I've read it and your argument is strong. I think my opinion
slightly moves towards Andreas, away from magic.

here is something I wrote some days ago:
https://github.com/midorikocak/arraytools/blob/master/src/ArrayConvertableTrait.php

I guess you were saying something like this would be enough.

Midori

On Tue, 4 Feb 2020 at 11:31, Marco Pivetta <ocramius@gmail.com> wrote:

> Hey Midori, > > This has been discussed in more depth 2 years ago: > https://externals.io/message/98539#98539 > > In practice, the `(array)` cast is one of the few operations that don't > cause observable side-effects in this programming language: let's please > keep it as such. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > > On Tue, Feb 4, 2020 at 8:15 AM Midori Koçak <mtkocak@gmail.com> wrote: > >> As you know we have __toString method that runs whenever an object is >> typecasted to string or it is directly echoed. >> >> > >> $class = (new class{ >> public function __toString(){ >> echo "casted\n"; >> return "mahmut\n"; >> } >> }); >> >> echo $class; >> $casted = (string)$class; >> >> /* >> prints: >> casted >> mahmut >> casted >> mahmut >> */ >> >> >> As you know toArray() method implemented when an object is converted into >> and array and most of the time when a plain data object is sent to >> front-end. >> >> Having a magic method like __toString called __toArray would be useful to >> detect and act on conversion events. >> >> Roughly it would be like: >> >> > >> $class = (new class{ >> public function __toArray(){ >> echo "casted\n"; >> return >> [ >> 'key'=>'value' >> ]; >> } >> }); >> >> >> $casted = (array)$class; >> print_r($casted); >> >> /* >> prints: >> Array >> ( >> [key] => value >> ) >> mahmut >> */ >> >> What would you think? I think it would add value. >> >
  108361
February 4, 2020 10:37 ocramius@gmail.com (Marco Pivetta)
Hey Midori,
<http://ocramius.github.com/>


On Tue, Feb 4, 2020 at 11:35 AM Midori Koçak <mtkocak@gmail.com> wrote:

> Marco, I've read it and your argument is strong. I think my opinion > slightly moves towards Andreas, away from magic. > > here is something I wrote some days ago: > https://github.com/midorikocak/arraytools/blob/master/src/ArrayConvertableTrait.php > > I guess you were saying something like this would be enough. > > Midori > > Correct: an explicit `$foo->toArray()` call suffices.
For other readers, more about `$foo->toArray()` vs `(array) $foo` is described at https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229 Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
  108363
February 4, 2020 11:19 rowan.collins@gmail.com (Rowan Tommins)
On Tue, 4 Feb 2020 at 10:37, Marco Pivetta <ocramius@gmail.com> wrote:

> Correct: an explicit `$foo->toArray()` call suffices. > > For other readers, more about `$foo->toArray()` vs `(array) $foo` is > described at > > https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229 >
The pros and cons of overloading casts are roughly the same as those of operator overloading in general: on one hand: + It is more succinct than calling a method + It aids creation of richer Domain Specific Languages on the other: - It is less explicit than choosing a purpose-specific method name - It is less flexible than having multiple related methods, or a method with parameters - It is harder to predict behaviour at a glance
> Or we can deprecate __toString() method at all and detect cast events > instead. Would it make more sense? Something like this __casted().
If there was a good case made for how it should work, I'd be more supportive of a general feature to overload casting, rather than making (array) a special case. One of many challenges would be working out when the cast should happen implicitly. Should "iterable $foo" trigger an array cast if the object isn't iterable? Should foreach()? Should strict_types change that behaviour as it does for __toString(), even though it currently only applies to scalar types? Regards, -- Rowan Tommins [IMSoP]
  108368
February 4, 2020 12:55 tom@inventis.be (Tom Gerrits)
> Correct: an explicit `$foo->toArray()` call suffices. > > For other readers, more about `$foo->toArray()` vs `(array) $foo` is > described at > > https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229
This is a valid point. Perhaps another problem lies at its base: why can one cast null to a string in PHP? Would it be more appropriate to throw a CastError or similar? Or does casting null to another type make sense in some scenarios? One could go as far as to only allow types that overload the appropriate cast operator to cast to the type without error. This implies the question of how to handle built-in types, such as casting floats to string.
> - It is less explicit than choosing a purpose-specific method name
I think it's also important to mention whether this discussion is about explicit casts only, or not - and also about implicit casts, or coercion. "(string) $var" doesn't seem a lot less explicit to me than "$var->toString()", but if it is coerced automatically when being passed to e.g. a function taking a string, that is of course a different story. Coercions and implicit casting using the overloaded operators could perhaps also be limited to non-strict mode, if desired, which is also the case for scalar types currently, IIRC.
  108372
February 4, 2020 13:13 ocramius@gmail.com (Marco Pivetta)
Hey Tom,

On Tue, Feb 4, 2020 at 1:55 PM Tom Gerrits <tom@inventis.be> wrote:

> "(string) $var" doesn't seem a lot less explicit to me than > "$var->toString()", but if it is coerced automatically when being > passed to e.g. a function taking a string, that is of course a > different story. >
`(string) $var` is less explicit because `(string)` is an operation that applies to a wide set of types, whereas any `->` applies only to `object` types, and also has a specific name (the method name) on its right. Restricting that operation to fewer supported types is not feasible at this point, since `(string) null` is very much relied upon. Coercions and implicit casting using the overloaded operators could
> perhaps also be limited to non-strict mode, if desired, which is also > the case for scalar types currently, IIRC. >
Is there any newly written code that doesn't use non-strict mode at all? Programming without `declare(strict_types=1)` seems anachronistic at this point. Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/