Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118059
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Reply-To: Stefan Marr <php@stefan-marr.de>
In-Reply-To: <CAOWwgp=AP34r9krBELzneDvEz1-TT9sSe6qfkjGSs9PJC6Fb2A@mail.gmail.com>
Date: Wed, 22 Jun 2022 18:39:35 +0100
Cc: shinji igarashi <sji@sj-i.dev>,
 php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <47080817-4B05-49C9-ABC1-B1EFF55905A7@stefan-marr.de>
References: <CAH19jWitAAqEdBrqX3ZjGnw+Nfd_8C=qzqPyxnOM13EtgZhBvA@mail.gmail.com>
 <029d3b2e-e8d3-41d0-acc9-7f7514651030@www.fastmail.com>
 <CAOWwgp=AP34r9krBELzneDvEz1-TT9sSe6qfkjGSs9PJC6Fb2A@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Constants in traits
From: internals@lists.php.net ("Stefan Marr via internals")

Hi Nicolas:

> On 22 Jun 2022, at 17:31, Nicolas Grekas =
<nicolas.grekas+php@gmail.com> wrote:
>=20
> > 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 =
English wordings.
> >
> > Thanks!
> >
> > --
> > Shinji Igarashi
>=20
> I am initially lukewarm.  One thing not addressed in the RFC that =
should 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 =
included it in the RFC.
So, my working assumption is: it wasn=E2=80=99t something I really =
thought 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) =
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

--=20
Stefan Marr
School of Computing, University of Kent
https://stefan-marr.de/research/