Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122090
MIME-Version: 1.0
References: <CAGgaK7+w_zdp30Pi5nJ-y+GPEkfc2xHfFUW+DwdpNtY8iPjMHg@mail.gmail.com>
 <CAOWwgpkW65ngNVrtu3oZ3_yAw4W+Qe1DsQ9LN-pfet_Psdy==Q@mail.gmail.com>
In-Reply-To: <CAOWwgpkW65ngNVrtu3oZ3_yAw4W+Qe1DsQ9LN-pfet_Psdy==Q@mail.gmail.com>
Date: Wed, 3 Jan 2024 09:36:05 +0100
Message-ID: <CABdc3WrjXkZSwfi+6mxDizKURhy7w8VUXoiAXEEytnwpGCEaUg@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: Max Semenik <maxsem.wiki@gmail.com>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000344127060e0682f0"
Subject: Re: [PHP-DEV] [RFC][Discussion] NotSerializable attribute
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--000000000000344127060e0682f0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Nicolas,

=C5=9Br., 3 sty 2024 o 08:12 Nicolas Grekas <nicolas.grekas+php@gmail.com>
napisa=C5=82(a):

> Hi Max,
>
> Hi, I'd like to propose a new attribute, #[NotSerializable]. This
> > functionality is already available for internal classes - userspace
> should
> > benefit from it, too.
> >
> > The RFC: https://wiki.php.net/rfc/not_serializable
> > Proposed implementation: https://github.com/php/php-src/pull/12788
> >
> > Please let me know what you think.
> >
>
> Regarding the inheritance-related behavior ("The non-serializable flag is
> inherited by descendants"), this is very unlike any other attributes, and
> this actively prevents writing a child class that'd make a parent
> serializable if it wants to.
>
> To me, if this is really the behavior we want, then the attribute should =
be
> replaced by a maker interface.
> Then, a simple "instanceof NotSerializable" would be enough instead of
> adding yet another method to ReflectionClass.
>

This should be possible without ReflectionClass, see https://3v4l.org/N3fmO
A property redeclare doesn't inherit the attributes, therefore this might
be a solution for the problem you presented.
Another ad-hoc way could be implementing `__serialize()` in the child class=
.

I like this feature and the only thing I'd like to consider is different
naming options for voting.

From the serialization libraries you can find similar attributes, these are=
:
* https://github.com/Crell/Serde `#[Crell\Serde\Attributes\Field(exclude:
true)]`
* https://github.com/symfony/serializer
`#[Symfony\Component\Serializer\Attribute\Ignore]`
* https://github.com/schmittjoh/serializer
`#[JMS\Serializer\Annotation\Exclude]`

In the Java world also:
* Java EE or Jakarta EE and using JAX-RS `@Transient`
* Jackson `@JsonIgnore`

In the C# world
* .NET _System.Text.Json.Serialization_ `[JsonIgnore]`

So there might be some other naming proposals like maybe just `Ignore` or
`Exclude` ?

What is worth mentioning are solutions allowing to change the strategy on
inheritance which JMS/Serializer supports
https://jmsyst.com/libs/serializer/master/reference/annotations#exclusionpo=
licy

The `#[ExclusionPolicy]` allows to declare that all properties should be
excluded or none.

Worth mentioning a future scope could introduce more interesting solutions
like:
* Exclude/Ignore conditionally on class or property level, for eg:
  a. if the value is null,
  b. or is undefined or
  c. its value is the default value - which allows to skip serialization of
properties with default values that will be unserialized back with the
default value - see https://3v4l.org/6b1Y6

Similar solutions used by:
* JMS/Serializer `#[JMS\Serializer\Annotation\SkipWhenEmpty]
* .NET `[JsonIgnore(Condition =3D JsonIgnoreCondition.WhenWritingDefault)]`
see
https://learn.microsoft.com/en-us/dotnet/api/system.text.json.serialization=
.jsonignorecondition?view=3Dnet-8.0

Cheers,
Micha=C5=82 Marcin Brzuchalski

--000000000000344127060e0682f0--