On 28/03/2023 00:36, G. P. B. wrote:
Hello internals,
While working on analysing the impact of the changes proposed by amending
the behaviour of the increment and decrement operators (
https://wiki.php.net/rfc/saner-inc-dec-operators) I discovered that the
range() function has some rather lax be
On Wed, Mar 29, 2023, at 4:28 PM, Mark Baker wrote:
> Another benefit of this approach would be to allow the inclusion of
> multiple enums, in the same way that we can include multiple traits.
>
>
> enum HttpErrors {
>
> case HTTP_STATUS_400;
>
> case HTTP_STATUS_401;
>
> …
>
> }
Hi,
[Proposal]
Allow interfaces to define properties. The implementing class must
have the same properties with the same name/type.
As the goal of the interfaces is to define the public "surface" of
the implementing class, I think that the public properties are also
part of that.
[Use case] -
Hi
On 28/03/2023 14:42, G. P. B. wrote:
> On Tue, 28 Mar 2023 at 08:19, Christian Schneider
> wrote:
>
>> Am 28.03.2023 um 00:36 schrieb G. P. B. :
>>> I therefore propose the "Define proper semantics for range() function"
>> RFC
>>> to address the unintuitive behaviour that sees no usage and/or
On 29/03/2023 16:43, Mark Baker wrote:
On 29/03/2023 16:31, Davey Shafik wrote:
On Mar 29, 2023, at 06:56, Rowan Tommins
wrote:
On Wed, 29 Mar 2023 at 14:22, Rokas Šleinius
wrote:
Ok so I am trying to find the argumentation here:
This is by design.
The point of enums is to be limiting
Hi
On 3/29/23 13:01, Rokas Šleinius wrote:
There's a hypothetical (based on a similar real world problem that I
am facing) example for the use of extending enums in the OP.
And I don't suppose Tim was arguing for not allowing enum
extendability, but rather contributing a real world example wher
Hi
On 3/29/23 12:41, Christian Schneider wrote:
And to give a specific example from PHP 8.3: As part of the Randomizer additions RFC
(https://wiki.php.net/rfc/randomizer_additions), PHP 8.3 got its first "natively
included" enum (\Random\IntervalBoundary). This enum works together with the new
On Wed, Mar 29, 2023, at 2:25 PM, Rokas Šleinius wrote:
> First, I'm pretty sure I agree now that enums should *not* be
> `extend`-ed as regular classes, there's a fundamental difference as
> you state - the extended enum is a fundamentally different THING as it
> can hold different values - when a
On Wed, 29 Mar 2023 at 15:26, Rokas Šleinius
wrote:
> Invoking it must provide a unique ErrorCode.
The concept of "uniqueness" only makes sense within a certain context - the
CMS easily create these two enums:
enum HttpErrorCode: int extends ErrorCode {
case NotFound = 404;
}
enum SQLErrorC
On 29/03/2023 16:31, Davey Shafik wrote:
On Mar 29, 2023, at 06:56, Rowan Tommins wrote:
On Wed, 29 Mar 2023 at 14:22, Rokas Šleinius wrote:
Ok so I am trying to find the argumentation here:
This is by design.
The point of enums is to be limiting.
This is clearly an assumption. That state
> On Mar 29, 2023, at 06:56, Rowan Tommins wrote:
>
> On Wed, 29 Mar 2023 at 14:22, Rokas Šleinius wrote:
>
>> Ok so I am trying to find the argumentation here:
>>> This is by design.
>>> The point of enums is to be limiting.
>> This is clearly an assumption. That statement is not in the doc
First, I'm pretty sure I agree now that enums should *not* be
`extend`-ed as regular classes, there's a fundamental difference as
you state - the extended enum is a fundamentally different THING as it
can hold different values - when an enum's sole purpose is to hold one
of the set of values.
That
On Wed, 29 Mar 2023 at 14:22, Rokas Šleinius wrote:
> Ok so I am trying to find the argumentation here:
>
> >This is by design.
> >The point of enums is to be limiting.
>
> This is clearly an assumption. That statement is not in the docs or
> RFC, nor such an oversimplification makes logical sens
Ok so I am trying to find the argumentation here:
>This is by design.
>The point of enums is to be limiting.
This is clearly an assumption. That statement is not in the docs or
RFC, nor such an oversimplification makes logical sense to me, but
maybe you have a source to back it up..?
>Re: proble
On Wed, 29 Mar 2023 at 13:30, G. P. B. wrote:
> On Wed, 29 Mar 2023 at 09:31, Rokas Šleinius wrote:
> > Enums were implemented as final so they cannot be extended nor can extend
> > anything else.
> >
>
> This is by design.
> Enumerations are in type theory parlance sum types.
> Objects in PHP,
On Wed, 29 Mar 2023 at 09:31, Rokas Šleinius wrote:
> Enums were a very useful addition to PHP, however one aspect of them is
> neither
> explicitly documented - or seemingly even talked about.
>
> Enums were implemented as final so they cannot be extended nor can extend
> anything else.
>
This
Hi!
There's a hypothetical (based on a similar real world problem that I
am facing) example for the use of extending enums in the OP.
And I don't suppose Tim was arguing for not allowing enum
extendability, but rather contributing a real world example where
users who were having some totally lega
Thank you for all the insight, I feel like having extendable enums
is an agreeable and organic way forward, so if I may, I would like
to go ahead and create an RFC draft for this and keep adding the
discussion outcomes till it settles for good.
If I can get the Karma to do so, of course, my wiki n
Am 29.03.2023 um 11:55 schrieb Tim Düsterhus :
> On 3/29/23 11:42, Sebastian Bergmann wrote:
>> Am 29.03.2023 um 11:31 schrieb Rokas Šleinius:
>>> I wouldn't say removing the final attribute from enums actually "breaks"
>>> any functionality.
>> I am with Marco on this: removing the "finality" fro
Hi
On 3/29/23 11:42, Sebastian Bergmann wrote:
Am 29.03.2023 um 11:31 schrieb Rokas Šleinius:
I wouldn't say removing the final attribute from enums actually "breaks" any
functionality.
I am with Marco on this: removing the "finality" from enum would be a
major backward compatiblity break as
Am 29.03.2023 um 11:31 schrieb Rokas Šleinius:
I wouldn't say removing the final attribute from enums actually "breaks" any
functionality.
I am with Marco on this: removing the "finality" from enum would be a
major backward compatiblity break as it breaks a fundamental assumption
about enums
> BC break
Hm, do you really think so? I wouldn't say removing the final
attribute from enums
actually "breaks" any functionality.
It WOULD allow some potentially illicit hacking to the end users of
our code, that's
true. I'd say a minor possibility of impact.
And anyway, isn't that what got you
Hey Rokas,
The idea of declaring an enum `abstract` is potentially worth exploring
(I'm not convinced, but go for it), but beware that removing the implicit
`final` from ENUMs is a BC break, since it breaks the assumption that an
ENUM is a sealed type.
If you design a proposal now, you need to co
> to restrict options within a certain range.
Okay that's an aspect of enums that I never gave much thought to, but
you're completely right.
However to be explicit about that aspect of functionality one would
then have to also be
allowed to define final enums.
That way you still have both options
On Wed, Mar 29, 2023 at 10:31 AM Rokas Šleinius wrote:
>
> Enums were a very useful addition to PHP, however one aspect of them is
> neither
> explicitly documented - or seemingly even talked about.
>
> Enums were implemented as final so they cannot be extended nor can extend
> anything else.
>
>
The point of an ENUM is precisely to restrict options within a certain
range.
Assume you declared `ErrorCode` with `SOMETHING_BROKE` and `PEBKAC` as
possible enumeration values.
If you can (somewhere, anywhere in the code) check `instanceof ErrorCode`,
then you know it can only be `SOMETHING_BROK
Enums were a very useful addition to PHP, however one aspect of them is neither
explicitly documented - or seemingly even talked about.
Enums were implemented as final so they cannot be extended nor can extend
anything else.
>From a user perspective it's surprising - and actually limiting.
USAGE
27 matches
Mail list logo
