> Am 29.01.2021 um 18:15 schrieb Larry Garfield
> :
>
> And we're back again. The RFC has been updated with a steady stream of
> smaller improvements based on feedback and testing, and is now in its Final
> Form(tm) (we think). The only major change worth noting is that we
On Mon, 25 Jan 2021 at 02:29, Larry Garfield wrote:
> Aside from some nitpicking around reflection and possibly fiddling with
> the naming of "Scalar Enum" et al, we're closing in on the final version.
> It will probably go to a vote in the not too distant future.
>
> --Larry Garfield
>
> --
>
On Mon, Dec 28, 2020, at 2:21 PM, Larry Garfield wrote:
> Hello, Internalians!
>
> After considerable discussion and effort, Ilija and I are ready to
> offer you round 2 on enumerations. This is in the spirit of the
> previous discussion, but based on that discussion a great deal has been
>
On Tue, Jan 5, 2021 at 6:56 PM Larry Garfield
wrote:
> On Tue, Jan 5, 2021, at 8:26 AM, Nikita Popov wrote:
>
> > Nice work, I like the updated proposal. Some notes:
> >
> > > Similarly, enum names and case names are both case insensitive.
> >
> > I agree that enum names should be case
On Tue, Jan 5, 2021, at 8:26 AM, Nikita Popov wrote:
> Nice work, I like the updated proposal. Some notes:
>
> > Similarly, enum names and case names are both case insensitive.
>
> I agree that enum names should be case insensitive (like class names), but
> why should case names be case
On Mon, Dec 28, 2020 at 9:22 PM Larry Garfield
wrote:
> Hello, Internalians!
>
> After considerable discussion and effort, Ilija and I are ready to offer
> you round 2 on enumerations. This is in the spirit of the previous
> discussion, but based on that discussion a great deal has been
On 04/01/2021 22:04, Mike Schinkel wrote:
I don't quit get how you are thinking of with ": string"; can you give an
example?
The current RFC requires the declaration of a Scalar Enum [1] to include
the scalar type, so it looks like this:
enum BookingStatus: string {
case PENDING =
On Mon, 4 Jan 2021 at 15:21, Pierre R. wrote:
> I do not agree with having values per default, this is error prone in
> most of my use cases.
>
> In most case where I need enums, I often need to replicate those in
> database too, or in message broker serialized messages: in this context,
>
> On Jan 4, 2021, at 9:05 AM, Rowan Tommins wrote:
>
> On 04/01/2021 11:15, Markus Fischer wrote:
>> On 03.01.21 12:01, Mike Schinkel wrote:
>>> So in my perfect world this:
>>>
>>> enum BookingStatus {
>>> case PENDING;
>>> case CONFIRMED;
>>> case CANCELLED;
>>> }
>>>
>>>
Le 04/01/2021 à 16:12, Markus Fischer a écrit :
I can't say whether just `: string` is too much, but in general I like
it.
I can follow the reasoning having no value by default and opt this in.
The opt-in you suggested is very low-overhead (albeit a bit subtle,
but maybe someone has a
On 04.01.21 16:12, Markus Fischer wrote:
I can't say whether just `: string` is too much, but in general I like it.
Apologies, I meant to write "too magic" :}
- Markus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hi,
On 04.01.21 15:05, Rowan Tommins wrote:
On 04/01/2021 11:15, Markus Fischer wrote:
On 03.01.21 12:01, Mike Schinkel wrote:
So in my perfect world this:
enum BookingStatus {
case PENDING;
case CONFIRMED;
case CANCELLED;
}
Would be equivalent to:
enum BookingStatus {
On 04/01/2021 11:15, Markus Fischer wrote:
On 03.01.21 12:01, Mike Schinkel wrote:
So in my perfect world this:
enum BookingStatus {
case PENDING;
case CONFIRMED;
case CANCELLED;
}
Would be equivalent to:
enum BookingStatus {
case PENDING = "PENDING";
case
Hi,
On 03.01.21 12:01, Mike Schinkel wrote:
So in my perfect world this:
enum BookingStatus {
case PENDING;
case CONFIRMED;
case CANCELLED;
}
Would be equivalent to:
enum BookingStatus {
case PENDING = "PENDING";
case CONFIRMED = "CONFIRMED";
case
On Sun, Jan 3, 2021, at 2:25 PM, Marc wrote:
> >> You already provide a lookup mechanism with `MyEnum::from()` - I don't
> >> see a real use-case for proving a pre build map. The main use case I see
> >> is to list all possible enum values but this doesn't require a map and a
> >>
Hi Ilija,
On 03.01.21 12:54, Ilija Tovilo wrote:
Hi Marc
I don't have a really good use-case for float values. It just seems
weird to me that a ScalarEnum doesn't support all scalars.
Using the enum value as array key for `cases()` works with your current
proposal but if we later want to
Hi Marc
> I don't have a really good use-case for float values. It just seems
> weird to me that a ScalarEnum doesn't support all scalars.
>
> Using the enum value as array key for `cases()` works with your current
> proposal but if we later want to allow floats, bool whatever then we got
> a
On 03.01.21 11:56, Marc wrote:
> On 29.12.20 16:42, Larry Garfield wrote:
>> On Tue, Dec 29, 2020, at 2:48 AM, Marc wrote:
>>> On 28.12.20 21:21, Larry Garfield wrote:
Hello, Internalians!
After considerable discussion and effort, Ilija and I are ready to offer
you round 2 on
> On Dec 31, 2020, at 12:15 PM, Larry Garfield wrote:
>
> On Thu, Dec 31, 2020, at 6:53 AM, Rowan Tommins wrote:
>> On 30/12/2020 21:24, Aleksander Machniak wrote:
>>> My argument is that, from an end-user perspective, I don't really see
>>> why Unit and Scalar enums have to have different
On 29.12.20 16:42, Larry Garfield wrote:
> On Tue, Dec 29, 2020, at 2:48 AM, Marc wrote:
>> On 28.12.20 21:21, Larry Garfield wrote:
>>> Hello, Internalians!
>>>
>>> After considerable discussion and effort, Ilija and I are ready to offer
>>> you round 2 on enumerations. This is in the spirit
On Fri, Jan 1, 2021, at 12:08 PM, Benjamin Eberlei wrote:
> On Mon, Dec 28, 2020 at 9:22 PM Larry Garfield
> wrote:
>
> > Hello, Internalians!
> >
> > After considerable discussion and effort, Ilija and I are ready to offer
> > you round 2 on enumerations. This is in the spirit of the previous
On Mon, Dec 28, 2020 at 9:22 PM Larry Garfield
wrote:
> Hello, Internalians!
>
> After considerable discussion and effort, Ilija and I are ready to offer
> you round 2 on enumerations. This is in the spirit of the previous
> discussion, but based on that discussion a great deal has been
On Thu, Dec 31, 2020, at 4:02 AM, Michał Marcin Brzuchalski wrote:
> Hi Larry,
> I really like the shape of the current RFC.
>
> I'd like to ask a few things:
>
> 1. Regarding the Scalar Enums since scalar values need to be literal and
> by design they're read only why they use a spear
On Thu, Dec 31, 2020, at 6:53 AM, Rowan Tommins wrote:
> On 30/12/2020 21:24, Aleksander Machniak wrote:
> > My argument is that, from an end-user perspective, I don't really see
> > why Unit and Scalar enums have to have different "API" at this point.
> > I'm talking about ":string"/":int" in the
On 30/12/2020 21:24, Aleksander Machniak wrote:
My argument is that, from an end-user perspective, I don't really see
why Unit and Scalar enums have to have different "API" at this point.
I'm talking about ":string"/":int" in the enum definiton as well as
->value and ->from().
My personal
On 30/12/2020 19:47, Larry Garfield wrote:
That's partially left over from when we had per-case methods, where grouping
would be highly fugly. However, I'm still advocating for tagged unions (in a
future step) having per-case methods, and that would make the grouping syntax
fugly again.
Hi Larry,
pon., 28 gru 2020 o 21:22 Larry Garfield
napisał(a):
> Hello, Internalians!
>
> After considerable discussion and effort, Ilija and I are ready to offer
> you round 2 on enumerations. This is in the spirit of the previous
> discussion, but based on that discussion a great deal has
On 30.12.2020 21:21, Larry Garfield wrote:
>> enum Suit {
>> case Hearts = 'H';
>> case Diamonds = 'D';
>> case Clubs = 'C';
>> case Spades = 'S';
>> }
>>
>> 'H' === Suit::Hearts->value; // true
>> 'Hearts' === Suit::Hearts->value; // false
>
> That's a possibility we've been kicking
On Wed, Dec 30, 2020, at 12:30 PM, Aleksander Machniak wrote:
> On 28.12.2020 21:21, Larry Garfield wrote:
> > https://wiki.php.net/rfc/enumerations
> Why can't this be simplified to:
>
> enum Size {
> case Small;
> case Medium;
> case Large;
> }
>
> 'Small' === Size::Small->value; // true
On Wed, Dec 30, 2020, at 6:27 AM, Rowan Tommins wrote:
> On 28/12/2020 20:21, Larry Garfield wrote:
> > After considerable discussion and effort, Ilija and I are ready to offer
> > you round 2 on enumerations.
>
>
> Thank you both, again, for all your efforts. I'm pleased to say that I
> like
On Wed, Dec 30, 2020, at 4:12 AM, Alexandru Pătrănescu wrote:
> Nice evolution overall.
>
> Few notes:
> - I think ScalarEnum::fromValue() would be more clear than just from() and
> more in sync with ->value property.
Any name would work, I suppose. I prefer short, single-word methods where
On 28.12.2020 21:21, Larry Garfield wrote:
> https://wiki.php.net/rfc/enumerations
Why can't this be simplified to:
enum Size {
case Small;
case Medium;
case Large;
}
'Small' === Size::Small->value; // true
Size::from('Small') === Size::Small; // true
enum Suit {
case Hearts = 'H';
On Wed, Dec 30, 2020, at 2:43 AM, Markus Fischer wrote:
> Hi,
>
> On 28.12.20 21:21, Larry Garfield wrote:
> > The full RFC is here, and I recommend reading it again in full given how
> > much was updated.
> >
> > https://wiki.php.net/rfc/enumerations
>
> I tried to answer the following
>
> What's the quickest way (=less code) to have an enum represent it's
> lexical name as the literal values?
>
> So that `… case Foo; case Bar; …` results in `::Foo->value === 'Foo'` etc.?
>
> Is this possible without implementing this manually for all cases?
>
>
AFAICS, you'd need to implement
On 30.12.20 12:00, Rowan Tommins wrote:
On 30 December 2020 08:43:33 GMT+00:00, Markus Fischer
wrote:
What is the scalar value for a ScalarEnum if none is explicitly
defined?
The question has no answer, because the declaration of the enum itself would be
invalid:
If an enumeration is
On 28/12/2020 20:21, Larry Garfield wrote:
After considerable discussion and effort, Ilija and I are ready to offer you
round 2 on enumerations.
Thank you both, again, for all your efforts. I'm pleased to say that I
like this draft even more than the last one. :)
A couple of points that
On 30 December 2020 08:43:33 GMT+00:00, Markus Fischer
wrote:
>What is the scalar value for a ScalarEnum if none is explicitly
>defined?
The question has no answer, because the declaration of the enum itself would be
invalid:
> If an enumeration is marked as having a scalar equivalent, then
On Mon, Dec 28, 2020 at 10:22 PM Larry Garfield
wrote:
>
> Hello, Internalians!
>
> After considerable discussion and effort, Ilija and I are ready to offer
you round 2 on enumerations. This is in the spirit of the previous
discussion, but based on that discussion a great deal has been reworked.
Hi,
On 28.12.20 21:21, Larry Garfield wrote:
The full RFC is here, and I recommend reading it again in full given how much
was updated.
https://wiki.php.net/rfc/enumerations
I tried to answer the following question but failed to do so:
What is the scalar value for a ScalarEnum if none is
On Tue, Dec 29, 2020, at 2:48 AM, Marc wrote:
>
> On 28.12.20 21:21, Larry Garfield wrote:
> > Hello, Internalians!
> >
> > After considerable discussion and effort, Ilija and I are ready to offer
> > you round 2 on enumerations. This is in the spirit of the previous
> > discussion, but based
On 28.12.20 21:21, Larry Garfield wrote:
> Hello, Internalians!
>
> After considerable discussion and effort, Ilija and I are ready to offer you
> round 2 on enumerations. This is in the spirit of the previous discussion,
> but based on that discussion a great deal has been reworked. The
On Mon, Dec 28, 2020, at 6:40 PM, Benjamin Morel wrote:
> Hi Larry, thank you for the updated RFC!
> I love it, and having played with the implementation, I can say I love it
> so far as well.
>
> I have one suggestion regarding reflection:
> Shouldn't ReflectionCase expose an additional
Hi Larry, thank you for the updated RFC!
I love it, and having played with the implementation, I can say I love it
so far as well.
I have one suggestion regarding reflection:
Shouldn't ReflectionCase expose an additional getInstance() method, that
would return the case instance, such as
Hello, Internalians!
After considerable discussion and effort, Ilija and I are ready to offer you
round 2 on enumerations. This is in the spirit of the previous discussion, but
based on that discussion a great deal has been reworked. The main change is
that Enumeration Cases are now object
44 matches
Mail list logo
