Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118065
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> <CAH19jWi8juy4_QZafXtTz40d1SDNv0UOjxPE7V1FrYHjoztycw@mail.gmail.com>
In-Reply-To: <CAH19jWi8juy4_QZafXtTz40d1SDNv0UOjxPE7V1FrYHjoztycw@mail.gmail.com>
Date: Thu, 23 Jun 2022 06:34:06 +0900
Message-ID: <CAH19jWhcBA9PsYQ_ZjWfrxA0QOvAZJNvwTR7-ne1w=Lq-q3S-g@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)

Wow, nested blockquotes are disappeared completely in externas.io :-)

If anyone is reading the discussion via externals.io and misses the context=
,
please check the source of the email.
https://externals.io/email/118064/source

Thanks!

--
Shinji Igarashi

2022=E5=B9=B46=E6=9C=8823=E6=97=A5(=E6=9C=A8) 6:04 shinji igarashi <sji@sj-=
i.dev>:
>
> 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 thou=
ght 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=
 only
> behavior and no state, thereby avoiding the state conflict problem in
> diamond inheritance. In the original trait paper, it is assumed that the =
state
> 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 abou=
t
> 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 e=
ven if
> there is a conflict, if the programming language defaults to either merge=
 or
> having independent state, that default will work fine for half of the use=
 cases.
>
> PHP strikes a balance in this problem, allowing traits to define properti=
es,
> and choosing to deal with conflicts by merging states, and also marking
> any conflicting definitions with different visibility or default values a=
s 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 =
was
> 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 de=
fault
> to trait state as trait local, but allow the programmer to selectively us=
e
> 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 withi=
n
> 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@stefa=
n-marr.de>:
>
> >
> > Hi Nicolas:
> >
> > > On 22 Jun 2022, at 17:31, Nicolas Grekas <nicolas.grekas+php@gmail.co=
m> wrote:
> > >
> > > > I'd like to start a discussion on an RFC to allow defining constant=
s in traits.
> > > > https://wiki.php.net/rfc/constants_in_traits
> > > >
> > > > I'm looking forward to your feedback, including corrections on Engl=
ish wordings.
> > > >
> > > > Thanks!
> > > >
> > > > --
> > > > Shinji Igarashi
> > >
> > > I am initially lukewarm.  One thing not addressed in the RFC that sho=
uld be: Why were constants left out of traits previously
> >
> > Hm. This isn=E2=80=99t something that I remember coming up specifically=
 back then.
> > If it had been discussed in more detail, I=E2=80=99d probably have incl=
uded it in the RFC.
> > So, my working assumption is: it wasn=E2=80=99t something I really thou=
ght 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 fr=
om 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) =
could 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 =
method 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=
 simple.
> > 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/
> >
> >