Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106783
MIME-Version: 1.0
References: <FB70FDD7-53AA-4DB4-B747-6E109BE52C2E@gmail.com>
 <CADyq6sJZjFQm0W+P=7C0CWp-TbiL2kUL-yJLCbZcmU0Ycc6cuQ@mail.gmail.com> <CAOWwgpnASj3j8BXqoMAOhuHntmwOroivvNybbxxZV-GE_kaXqw@mail.gmail.com>
In-Reply-To: <CAOWwgpnASj3j8BXqoMAOhuHntmwOroivvNybbxxZV-GE_kaXqw@mail.gmail.com>
Date: Thu, 29 Aug 2019 05:09:39 +0200
Message-ID: <CAEPJdu=r5KTG7jtVER+zLRZCWXyX1XYcJK23pK6LKVhSMer20A@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas@gmail.com>
Cc: Marco Pivetta <ocramius@gmail.com>, Steven Wade <stevenwadejr@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b9b383059138d6bf"
Subject: Re: [PHP-DEV] Proposal for a RFC
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000b9b383059138d6bf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, May 5, 2019 at 5:08 PM Nicolas Grekas <nicolas.grekas@gmail.com>
wrote:

> Le sam. 4 mai 2019 =C3=A0 18:37, Marco Pivetta <ocramius@gmail.com> a =C3=
=A9crit :
>
> > Hi Steven,
> >
> > As it currently stands, the array cast is the only operation capable of
> > exposing object state without triggering any kind of access guards: it =
is
> > very much required for anything that works with reflection and typed
> > properties, and possibly the only operation in PHP that operates on sta=
te
> > without some contraption intercepting its execution.
> >
> > It is also necessary to distinguish dynamic properties from declared
> object
> > state.
> >
> > For comparison, all of the following have side-effects due to the
> > complexity of the language:
> >
> >  * isset()
> >  * unset()
> >  * property read
> >  * property write
> >  * ReflectionProperty#getValue()
> >  * ReflectionProperty#setValue()
> >
> > Overall, this is problematic, and introduces more magic that I'd gladly
> > avoid, in an endpoint used to work around all the engine magic (the onl=
y
> > stable one so far).
> >
> > From my end, this sounds like a bad idea, because it removes one of the
> > very very few referentially transparent guarantees (if not the only one=
,
> > when dealing with objects) from the language.
> >
> > Greets,
> >
> > Marco
> >
>
> I want to weight in with what Marco expressed. I have the very same
> concerns and they are major ones for many use cases. Mine is VarDumper.
>
> Please don't do this the way it is described.
>

Because Steve asked for wiki access to work on an RFC for his proposal, I
went back and re-read and just wanted to come in his support as I think it
would be a great addition to the existing __magic functionality,

I want to add a few more arguments why __toArray() should be added
regardless of the objections from Marco & Nicolas:

1. PHP already has __debugInfo() which affects the behavior of var_dump()
allowing users to control what gets exposed to it in a debugging context.
This is new magic method would affect Symfony's VarDumper+ VarCloner in a
similar consistent way that gives class owners back control of what gets
exposed. One primary benefit of OOP is encapsulation and guarding against
access of internal state from the outside, so it is questionable anyways
why an idiomatic and simple to use syntax like (array) $object would expose
internal state and a developer would have no means of preventing that.

2. Adding __toArray would not constitute a backwards compatibility break,
because all existing code does not implement __toArray and would keep the
same exact behavior.

3. You can't argue against the concept of magic methods overall by citing
your own use case that is objectively an extremely magic use of the
existing behavior of (array) $object itself. I can see a very good case to
change (array) $object to return only public properties as part of the
general push to cleanup inconsistent behavior in PHP 8. As Nikita
mentioned, it might make sense to add a function that is specifically
designed for your both use-cases instead and that would honestly make this
part of the language cleaner in the end and we can get rid of this *
protected and nullbyte private variable returning behavior once and for all=
.

4. ReflectionProperty::getValue() does not trigger a guard clause if you
call setAccessible(true) first, so I don't think the objection that this is
the only way to access private data is true here. Correct me if I forgot an
edge case that prevents this.

5. Arguments of API design that toSomethingString() is somehow "better"
than using __toString() and therefore the addition of __toArray() is bad
pit one paradigm (explicit OOP vs magic methods) and should be avoided in
an RFC discussion. We are also not discussing to remove functions in PHP
because we now have classes and methods and this falls into the same
category. Its a subject design decision and shouldn't influence the
expansion of an existing feature/paradigm that one doesn't use themselves.


> Nicolas
>

--000000000000b9b383059138d6bf--