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 "->value" on enumeration?
> A spear "->" in objects is dedicated to class properties and by default
> they make thinking of property which
> in most cases is read-write visible.
>
> An example using Suit enumeration from RFC:
> // when I assign an enumeration to variable
> $var = Suit::Spades;
> // then reaching it's value using "->value"
> echo $var->value; // 'C'
> // Looks just like an object property fetch
>
> By default if a property is visible it is write accessible as well, which
> may confuse.
>
> Instead of using spear "->value" would it be possible to fetch the value
> just like object constants?
>
> print Suit::Clubs::value; // 'C'
> echo $var::value; // 'C'
>
> This mentally indicates by default that it's value is constant, simple
> scalar value and read only!
We originally used a method in the first draft. We changed it to a property
for three reasons.
1) There's lots of talk lately about immutable properties, so one way or
another "it's a property so I can write to it" is an assumption that won't hold
much longer.
2) The property has to exist internally anyway, because under the hood it's
just a class with a property, so the name would still be reserved either way.
3) Given 1 and 2, adding a method on top just adds some micro overhead for the
method call.
A constant-esque syntax wouldn't be possible because under the hood, the cases
are objects now, not classes. We could put constants on Suit, but Suit::Clubs
is an object, and objects can't have constants independent of their class.
> 2. Regarding the Scalar Enums declaration syntax
>
> enum Suit: string {
> case Hearts = 'H';
> }
>
> Would it make sense to move the part declaring enumeration value before
> enum name?
> I think it was put here to look similar to function return type, but IMHO
> it looks better and reads easier
> when moved before enum name:
>
> enum:string Suit {
> case Hearts = 'H';
> }
>
> Leaving the space between enum name and bracket for further extensions in
> future.
> What do you think?
That would be a very one-off syntax. The colon-suffix is already established
in PHP, and i the same as the syntax used in Swift. What you're describing
looks a lot more like a generic. Which... I suppose in some ways this is if
you squint really hard? I don't have much of an argument against it other than
aesthetic. I have no idea what the parser would do with it.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
