Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118064
MIME-Version: 1.0
References: <CAH19jWitAAqEdBrqX3ZjGnw+Nfd_8C=qzqPyxnOM13EtgZhBvA@mail.gmail.com>
 <029d3b2e-e8d3-41d0-acc9-7f7514651030@www.fastmail.com> <CAOWwgp=AP34r9krBELzneDvEz1-TT9sSe6qfkjGSs9PJC6Fb2A@mail.gmail.com>
 <47080817-4B05-49C9-ABC1-B1EFF55905A7@stefan-marr.de>
In-Reply-To: <47080817-4B05-49C9-ABC1-B1EFF55905A7@stefan-marr.de>
Date: Thu, 23 Jun 2022 06:04:55 +0900
Message-ID: <CAH19jWi8juy4_QZafXtTz40d1SDNv0UOjxPE7V1FrYHjoztycw@mail.gmail.com>
To: Stefan Marr <php@stefan-marr.de>
Cc: Nicolas Grekas <nicolas.grekas+php@gmail.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Constants in traits
From: sji@sj-i.dev (shinji igarashi)

Hello Larry, Stefan, and Nicolas!

Thanks for the responses.

>>> Why were constants left out of traits previously
>> That!
> So, my working assumption is: it wasn=E2=80=99t something I really though=
t about.

From what I've read in the old ML archives of discussions on introducing
traits to PHP, perhaps constants simply were not among the considerations.
The phrase "constants" is rarely even mentioned in the discussion.

>> why the default value of a const (and a property) could not be changed
>> by the class importing the trait?

My answer to this question is that there can be more than one policy for
handling state conflicts, and PHP has implemented one restricted approach
for now and has not yet addressed another policy after that.

Based on my limited understanding, let me briefly summarize the story.
Please point out if anything is incorrect.

First, it should be noted that in the original trait paper, the trait has o=
nly
behavior and no state, thereby avoiding the state conflict problem in
diamond inheritance. In the original trait paper, it is assumed that the st=
ate
is provided on the composing class side and accessed from the trait
through the accessor [1]. With this pure approach in mind, PHP allows
abstract methods to be declared in the trait, and the composing class
implements the requested accessors.

The problem with this pure approach is obvious: there is too much
boilerplate in creating and using traits. Traits provide class components,
and serious class components will often want to access some state.
During the initial discussions, many messages were sent to internals about
whether to allow properties in traits, and what form this should take.

By the way, historically, there have been two typical approaches to the
diamond inheritance state collision problem: one is to merge the state of
the common ancestor, and the other is to have independent state for each
common ancestor in the separate "path". Since different use cases require
one or the other, programming languages sometimes have features that
allow programmers to use these two methods selectively, such as virtual
inheritance in C++.

Where having state becomes tricky is when the diamond problem occurs.
If there are no conflicts, it does not matter if a trait has state. And eve=
n if
there is a conflict, if the programming language defaults to either merge o=
r
having independent state, that default will work fine for half of the use c=
ases.

PHP strikes a balance in this problem, allowing traits to define properties=
,
and choosing to deal with conflicts by merging states, and also marking
any conflicting definitions with different visibility or default values as =
an
error, as a sign of an unintended name conflict [2].

This is how PHP came to have properties in traits in its current form; I
believe that the story of having data definitions instead of behaviors in
traits have barely settled itself, and the story of constant definitions wa=
s
simply forgotten or put on the back burner.

While not the main topic, current PHP does not yet provide a way to allow
common ancestors to have independent states. There are several
references to Stateful Traits in older discussions[3]. Stateful Traits defa=
ult
to trait state as trait local, but allow the programmer to selectively use
merge behavior as needed. On the contrary, since PHP defaults to merge
behavior, there may be a future extension that allows trait local to be
explicitly declared. This option has even been mentioned in the old
discussions, but it has not caught the attention of many people and has
been on hold for more than a decade [4]. Perhaps it is time to reconsider
this also.

>> And I'd also be happy to see an implementation of this before voting

Yeah of course! It is generally working on my end, and I'll send PR within
a few days after adding a few more minor test cases.

[1] https://dl.acm.org/doi/10.1145/1119479.1119483
[2] https://externals.io/message/51007#51072
[3] https://link.springer.com/chapter/10.1007/978-3-540-71836-9_4
[4] https://externals.io/message/35800

Thanks!

--
Shinji Igarashi

2022=E5=B9=B46=E6=9C=8823=E6=97=A5(=E6=9C=A8) 2:39 Stefan Marr <php@stefan-=
marr.de>:

>
> Hi Nicolas:
>
> > On 22 Jun 2022, at 17:31, Nicolas Grekas <nicolas.grekas+php@gmail.com>=
 wrote:
> >
> > > I'd like to start a discussion on an RFC to allow defining constants =
in traits.
> > > https://wiki.php.net/rfc/constants_in_traits
> > >
> > > I'm looking forward to your feedback, including corrections on Englis=
h wordings.
> > >
> > > Thanks!
> > >
> > > --
> > > Shinji Igarashi
> >
> > I am initially lukewarm.  One thing not addressed in the RFC that shoul=
d be: Why were constants left out of traits previously
>
> Hm. This isn=E2=80=99t something that I remember coming up specifically b=
ack then.
> If it had been discussed in more detail, I=E2=80=99d probably have includ=
ed it in the RFC.
> So, my working assumption is: it wasn=E2=80=99t something I really though=
t about.
>
>
> > and what has changed to make them make sense to include now?  (I don't =
recall, honestly, so I have no strong feelings one way or the other yet.)
>
> I am not sure there are reasons to specifically exclude them though.
> The RFC, reading over it briefly, and having been away for very long from=
 the topic, seems sensible to me.
> Taking a very restrictive approach, seems sensible to me, too.
>
> > I'm also wondering why the default value of a const (and a property) co=
uld not be changed by the class importing the trait? This sometimes hits me=
 and the original RFC doesn't explain why this is needed.
>
> For constants, I=E2=80=99d lean towards not allowing changes.
> If you need to parameterize the trait with a value, having an abstract me=
thod return it seems a much clearer way of doing it.
> Then all parts of the system know =E2=80=9Cit=E2=80=99s not a constant=E2=
=80=9D and I need to cater for different values.
>
> The reason for the strict policies on property conflicts was to keep it s=
imple.
> Be conservative, and avoid silent bugs.
>
>
> Please take everything I say with an extra pinch of salt.
> It has been a long time.
>
> Best regards
> Stefan
>
> --
> Stefan Marr
> School of Computing, University of Kent
> https://stefan-marr.de/research/
>
>