Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116016
MIME-Version: 1.0
References: <CAF+90c-Xze=9A66hfDggan-JrebJDNvS1LdU45_Lreg+LXGhuw@mail.gmail.com>
 <C618EE82-9F5A-46FB-8A99-6979F474625E@newclarity.net> <46f2e842-8608-0622-f1c1-3eb746658c84@gmail.com>
 <F0CC2358-D63C-4BF6-980F-4774262249FD@newclarity.net> <CANS-=pevbu-jUc35-7YxjuKE277zHyB60PyjBY9KNNSx6WYJoA@mail.gmail.com>
 <CAB-BujbE9REcP1E2Mh4aZSveYTLkiwL-NaCinPSYa8H9ZWbBAg@mail.gmail.com>
In-Reply-To: <CAB-BujbE9REcP1E2Mh4aZSveYTLkiwL-NaCinPSYa8H9ZWbBAg@mail.gmail.com>
Date: Wed, 8 Sep 2021 22:48:22 +0200
Message-ID: <CAB-BujZei5OtMoFH2FHJ7Yd_sqOKDse215YjsUGj9W7rc+LxZg@mail.gmail.com>
To: Lynn <kjarli@gmail.com>
Cc: Mike Schinkel <mike@newclarity.net>, Rowan Tommins <rowan.collins@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Alias stdClass to DynamicObject?
From: andreas@dqxtech.net (Andreas Hennings)

Wow!
I notice that ArrayObject already does everything we would need for
json_encode().

assert(json_encode(new ArrayObject([5])) === '{"0":5}');

However, it does so in a very strange way, not using any of the public
methods, but also not using dynamic properties.
It seems there is a hard-coded internal implementation when calling
json_encode() or converting to array.
https://3v4l.org/rAc4K

I think we would want something more clean and transparent.






On Wed, 8 Sept 2021 at 21:58, Andreas Hennings <andreas@dqxtech.net> wrote:
>
> On Wed, 8 Sept 2021 at 18:33, Lynn <kjarli@gmail.com> wrote:
> >
> > On Wed, Sep 8, 2021 at 5:38 PM Mike Schinkel <mike@newclarity.net> wrote:
> >
> > > A couple more things; add a `JSON_OUTPUT_DYNAMIC_OBJECT` flag to output to
> > > DynamicObject for `json_decode()`,  add a 3rd parameter for flags to
> > > var_export() for the same reason, a `'return_dynamic_object'` option for
> > > `unserialize()`, and so on.
> > >
> >
> > It would also be interesting to enter a user-defined class here to work as
> > a reversed JsonSerializable. Could be a static factory method for all I
> > care, and would omit the requirement of serialization libraries for
> > "simple" things where you still want decent object typing. Could also work
> > together with interfaces accepting properties, effectively making the
> > result of json_decode an anonymous class that still adheres to an
> > interface. In case of the custom 'deserialization' you can throw exceptions
> > if the format is not correct. In the case of an anonymous class with an
> > interface it could throw an exception if the structure doesn't match
> > (possibly controlled by flags?).
>
> I think we want round-trips of json_decode() + json_encode() to work
> loss-free, without any custom classes or extra parameters.
>
> Currently, '{}' and '[]' have different results with json_decode().
>
> assert(json_encode(json_decode('{}')) === '{}');  // Perfect round-trip.
> assert(json_encode(json_decode('{}', JSON_OBJECT_AS_ARRAY)) === '[]');
>  // Lossy round-trip.
>
> This can only work if we have a built-in data transfer object,
> distinct from arrays.
> Currently this is \stdClass, using the dynamic property mechanism.
>
> But one could easily imagine a different kind of data transfer object,
> which would use a different mechanism instead of dynamic properties.
>
> A native implementation of JsonSerializable does not really work here,
> because ->jsonSerialize() would have to return \stdClass to result in
> '{}'.
> Instead, what about something with a "->getData(): array" method, but
> then json_decode() would encode it as '{}'?
>
> assert(json_decode('{}') instanceof DataTransferObject);
> assert(json_decode('{}')->getData() === []);
> assert(json_encode(json_decode('{}')->getData()) === '[]');
> assert(json_encode(json_decode('{}')) === '{}');
>
> For the proposed rename:
> - If we can fully deprecate and replace dynamic properties long-term,
> I would rather keep the name \stdClass until it dies.
> - Instead of an alias or rename, I would rather have a new data
> transfer object class which would not rely on dynamic properties, but
> on a new mechanism.
>
> Imo, creating an alias won't actually make life easier for anyone,
> unless we can fully remove and replace \stdClass.
> It would mean that developers need to learn both names, and understand
> how aliases work - something you don't really need to learn otherwise.
> Think of the silly wtfs that can occur if people don't fully
> understand aliases, or are not aware that DynamicObject is just an
> alias, while \ReflectionClass and get_class() still return 'stdClass'
> as the class name.
>
> -- Andreas