On Wed, 8 Sept 2021 at 18:33, Lynn <kja...@gmail.com> wrote:
>
> On Wed, Sep 8, 2021 at 5:38 PM Mike Schinkel <m...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
