Re: [PHP-DEV] Let's discuss enums!

[Rowan Collins]

On 18 September 2015 01:49:35 BST, John Bafford  wrote:
>an important benefit to providing a value for enums would be to allow for
>changing or deprecating enums. So you might want to say something like:
>
>enum FormEvents {
>   PRE_SUBMIT,
>   PRE_BIND = PRE_SUBMIT, //deprecated name, provide mapping to new name
>}

I'm not sure whether I like it or not, but I note that Python allows this: 
every enum member must have a value, which can be of any type; if two members 
are given the same value, the later defined one is considered an alias of the 
first. There is a method to select an instance by value, which will always 
return the first member with that value, not the alias. The examples also 
include lots of ways of using the value with overloaded operators etc.

Regards,
-- 
Rowan Collins
[IMSoP]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Rowan Collins]

On 18 September 2015 18:31:55 BST, Lester Caine  wrote:
>On 18/09/15 00:06, Rowan Collins wrote:
>> So, what are anyone's thoughts? Am I rambling on too much as usual?
>;)
>
>What happens when you need to switch language?

Yes, the names of enum members should be considered labels, not descriptions. 
They're strings only for the convenience of programmers working with them, just 
like variable names, which would more  efficiently be written $1, $2, etc.

Your enum value might be State::OFF_MAP_E, which would be looked up in a 
database or translation library to the appropriate translation of "You are off 
the East side of the map".

Regards,
-- 
Rowan Collins
[IMSoP]


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Rowan Collins]

On 18 September 2015 15:42:44 BST, Anthony Ferrara  wrote:
>As far as enums, I wonder if they would be necessary if we supported
>algebraic types, since you could define an "enum" as a virtual type:
>
>const MONDAY = 0;
>const TUESDAY = 1;
>const WEDNESDAY = 2;
>const THURSDAY = 3;
>const FRIDAY = 4;
>use MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY as WEEKDAY;
>
>function foo(WEEKDAY $day) {
>// must be an integer 0-4, or castable to 0-4 unless strict_types is
>on.
>}


I think this is a fundamentally different style of enum to what Levi and I are 
thinking of.

In your example - and this seems to be what C# means by enum, for instance - 
it's a subset of a scalar type, usually an integer, with some names as 
mnemonics. Other than that it behaves exactly as the base type would, and can 
be readily cast, maybe even implicitly, to and from that base type.

The other style is where each enum type is a completely distinct type, not just 
a whitelist of values in some other domain. In a sense (and this is what got me 
thinking about enums recently), you can consider null to be an enum with only 
one value, and boolean to be an enum with two - you can define (int)true as 1, 
but true is not an integer, and 1 is not a boolean value.

I suspect both styles may have their place, but algebraic types certainly 
wouldn't take away my thirst for object-like enums.

Regards,
-- 
Rowan Collins
[IMSoP]


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Rowan Collins]

On 18 September 2015 08:05:11 BST, "Pavel Kouřil"  wrote:
>personally, I feel that you should be able to assign numeric value to
>each element (and have them implicit if not specified).
>
>This is imho better for serialization (but it can be done with names
>as well, yeah) - but more importantly, it also allows usage with
>bitwise operators, so you could use them as a "flags" (ie. $weekend =
>Days::SATURDAY | Days::SUNDAY).

That's actually two different requests: firstly, that every enum should have a 
numeric value, rather than it being opt-in. And secondly, that enums should 
have overloaded operators that allow their use in contexts where integers would 
be expected.

I draw that distinction because overloaded operators are fairly rare in PHP 
(and largely unavailable in userland).

In some languages (e.g. C#) enums are just a name for an integer, and can be 
readily compared to, and cast from or to, ordinary integers. That's one way of 
allowing operators to work on them, but it leads to things like Days::Monday == 
Months::January returning true, which doesn't feel right to me.

I think an enum-like type specifically for bitsets, which overloaded bitwise 
operators without ever exposing the underlying integers, might be interesting, 
though.

Regards,
-- 
Rowan Collins
[IMSoP]


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Jefferson Gonzalez]

On 09/18/2015 02:29 PM, Rowan Collins wrote:

Jefferson Gonzalez wrote on 18/09/2015 19:25:

I also believe the rfc should include type hinting of enums as has
been mentioned on this discussion. That would make enumerations more
useful and the rfc more complete.


It already mentions that:

 > Enums are strongly typed and can be used as parameter or return types.

As I understand it, this actually comes for free the way it's
implemented, because Enums are actually a type of object, and the enum
declaration is effectively a class.


Whoops... just noticed after re-reading the rfc :) thanks!

Then I guess the missing bits are an implementation (most important 
part) and a happy medium for those that believe that behind the scenes 
(serialization, storage, databases) enumerations should be represented 
numerically (for the various reasons discussed).


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Rowan Collins]

Jefferson Gonzalez wrote on 18/09/2015 19:25:
I also believe the rfc should include type hinting of enums as has 
been mentioned on this discussion. That would make enumerations more 
useful and the rfc more complete.


It already mentions that:

> Enums are strongly typed and can be used as parameter or return types.

As I understand it, this actually comes for free the way it's 
implemented, because Enums are actually a type of object, and the enum 
declaration is effectively a class.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Jefferson Gonzalez]

On 09/18/2015 01:21 PM, Levi Morrison wrote:

On Fri, Sep 18, 2015 at 11:18 AM, Rowan Collins  wrote:

Levi Morrison wrote on 18/09/2015 18:04:


Anything else is trying to add value in some way – in your case you
are adding a primitive value that the language will automatically map
for you. I'm not saying that is a bad thing but I hope you can at
least recognize that it is an addition and not the bare minimum. The
RFC I am planning on proposing will have only the bare minimum because
it's the least controversial part and is the most useful. The other
stuff we can debate about later.



That's why I was kind of surprised to see ordinal() in there in the draft -
it's an additional field on each member, which in many cases has no
relationship to the value being represented.


I suspect it will be removed before hitting the official discussion phase :D


Also, apologies for accidentally starting the discussion of your draft "too
early", I wasn't aware that you were working on it. I was trying to offer
something productive to the language, since I've been spending a lot of time
talking down new features lately. :)


No worries – it happens.



I also believe the rfc should include type hinting of enums as has been 
mentioned on this discussion. That would make enumerations more useful 
and the rfc more complete.


enum Weekday {SUNDAY=0, MONDAY=1, TUESDAY=2, WEDNESDAY=3}

function set_day(Weekday $day) : Weekday
{
// $day can only be numbers 0,1,2,3

//$return can only also be 0,1,2,3
}

Enums is a really needed feature for PHP that would have make code much 
more cleaner and easy to follow than what we have today.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Lester Caine]

On 18/09/15 00:06, Rowan Collins wrote:
> So, what are anyone's thoughts? Am I rambling on too much as usual? ;)

What happens when you need to switch language?

This is one area where a well formatted database system fills many
holes. Simply selecting a subset of entries from a table allows a user
to select the enumerated values in their language. We hit no end of
problems where English is encoded into the code rather than simply a set
of numbers.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Levi Morrison]

On Fri, Sep 18, 2015 at 11:18 AM, Rowan Collins  wrote:
> Levi Morrison wrote on 18/09/2015 18:04:
>>
>> Anything else is trying to add value in some way – in your case you
>> are adding a primitive value that the language will automatically map
>> for you. I'm not saying that is a bad thing but I hope you can at
>> least recognize that it is an addition and not the bare minimum. The
>> RFC I am planning on proposing will have only the bare minimum because
>> it's the least controversial part and is the most useful. The other
>> stuff we can debate about later.
>
>
> That's why I was kind of surprised to see ordinal() in there in the draft -
> it's an additional field on each member, which in many cases has no
> relationship to the value being represented.

I suspect it will be removed before hitting the official discussion phase :D

> Also, apologies for accidentally starting the discussion of your draft "too
> early", I wasn't aware that you were working on it. I was trying to offer
> something productive to the language, since I've been spending a lot of time
> talking down new features lately. :)

No worries – it happens.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Rowan Collins]

Levi Morrison wrote on 18/09/2015 18:04:

Anything else is trying to add value in some way – in your case you
are adding a primitive value that the language will automatically map
for you. I'm not saying that is a bad thing but I hope you can at
least recognize that it is an addition and not the bare minimum. The
RFC I am planning on proposing will have only the bare minimum because
it's the least controversial part and is the most useful. The other
stuff we can debate about later.


That's why I was kind of surprised to see ordinal() in there in the 
draft - it's an additional field on each member, which in many cases has 
no relationship to the value being represented.


Also, apologies for accidentally starting the discussion of your draft 
"too early", I wasn't aware that you were working on it. I was trying to 
offer something productive to the language, since I've been spending a 
lot of time talking down new features lately. :)


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Levi Morrison]

(CC'ing internals as it was apparently dropped by Jeff)

On Fri, Sep 18, 2015 at 11:03 AM, Levi Morrison  wrote:
> On Fri, Sep 18, 2015 at 9:59 AM, Jefferson Gonzalez  wrote:
>> On 09/18/2015 10:21 AM, Levi Morrison wrote:
>>>
>>> On Fri, Sep 18, 2015 at 1:05 AM, Pavel Kouřil  wrote:

 On Fri, Sep 18, 2015 at 1:06 AM, Rowan Collins 
 wrote:
>
> Hi All,
>
> This has come up in passing a few times recently, but I'm not sure
> there's
> ever been a dedicated discussion of it: would it be useful for PHP to
> have a
> built-in Enumeration type, and if so, how should it look?
>
> Many other languages have enum types, with varying functionality. The
> central concept is always that there's some declared type with a bunch
> of
> named constants, but beyond that there's a lot of variability: for
> starters,
> is it a type of object, a special way of naming integers, or an
> uncomparable
> type more like booleans and nulls?
>
>
> So, what are anyone's thoughts? Am I rambling on too much as usual? ;)
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>

 Hi,

 personally, I feel that you should be able to assign numeric value to
 each element (and have them implicit if not specified).

 This is imho better for serialization (but it can be done with names
 as well, yeah) - but more importantly, it also allows usage with
 bitwise operators, so you could use them as a "flags" (ie. $weekend =
 Days::SATURDAY | Days::SUNDAY).
>>>
>>>
>>> In my opinion this is the least valuable form of enums that exists in
>>> any language I am aware of. However I was careful in the RFC to not
>>> prevent this from being a possibility. I would much, much prefer enums
>>> that are more like Rust's, Haskell's or Swift's. It's worth noting
>>> Swift has at least three different kinds of enums, one of which would
>>> allow the kind of behavior you are wanting.
>>>
>>
>> It may not be valuable in your opinion, but I have seen this kind of enum
>> usage on a lot of open source projects which is really useful to represent
>> more than 1 value in a single variable, which would be more efficient and
>> less memory consuming than doing something like:
>>
>> $weekend = array(
>> Days::SATURDAY;
>> Days::SUNDAY;
>> )
>>
>> And anyway, most new languages have over engineered the purpose of enums.
>> Enums should just be a nice way of grouping constant values with a human
>> readable name where the ordinal value should be optionally set for
>> consistency in case that storing it is required.
>
> According to type theory the enumerated type is just a special case of
> the union type where each type constructor in the union takes exactly
> zero parameters (meaning they are all singletons). So… what is the
> purpose of an enumerated type? To create a finite set of values that
> are all unique. That's it – that's the whole purpose.
>
> Anything else is trying to add value in some way – in your case you
> are adding a primitive value that the language will automatically map
> for you. I'm not saying that is a bad thing but I hope you can at
> least recognize that it is an addition and not the bare minimum. The
> RFC I am planning on proposing will have only the bare minimum because
> it's the least controversial part and is the most useful. The other
> stuff we can debate about later.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Jefferson Gonzalez]

On 09/18/2015 10:21 AM, Levi Morrison wrote:

On Fri, Sep 18, 2015 at 1:05 AM, Pavel Kouřil  wrote:

On Fri, Sep 18, 2015 at 1:06 AM, Rowan Collins  wrote:

Hi All,

This has come up in passing a few times recently, but I'm not sure there's
ever been a dedicated discussion of it: would it be useful for PHP to have a
built-in Enumeration type, and if so, how should it look?

Many other languages have enum types, with varying functionality. The
central concept is always that there's some declared type with a bunch of
named constants, but beyond that there's a lot of variability: for starters,
is it a type of object, a special way of naming integers, or an uncomparable
type more like booleans and nulls?


So, what are anyone's thoughts? Am I rambling on too much as usual? ;)

Regards,

--
Rowan Collins
[IMSoP]



Hi,

personally, I feel that you should be able to assign numeric value to
each element (and have them implicit if not specified).

This is imho better for serialization (but it can be done with names
as well, yeah) - but more importantly, it also allows usage with
bitwise operators, so you could use them as a "flags" (ie. $weekend =
Days::SATURDAY | Days::SUNDAY).


In my opinion this is the least valuable form of enums that exists in
any language I am aware of. However I was careful in the RFC to not
prevent this from being a possibility. I would much, much prefer enums
that are more like Rust's, Haskell's or Swift's. It's worth noting
Swift has at least three different kinds of enums, one of which would
allow the kind of behavior you are wanting.



It may not be valuable in your opinion, but I have seen this kind of 
enum usage on a lot of open source projects which is really useful to 
represent more than 1 value in a single variable, which would be more 
efficient and less memory consuming than doing something like:


$weekend = array(
Days::SATURDAY;
Days::SUNDAY;
)

And anyway, most new languages have over engineered the purpose of 
enums. Enums should just be a nice way of grouping constant values with 
a human readable name where the ordinal value should be optionally set 
for consistency in case that storing it is required.


In any case this is a nice read:
https://en.wikipedia.org/wiki/Enumerated_type

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Jefferson Gonzalez]

On 09/18/2015 10:42 AM, Anthony Ferrara wrote:

As far as enums, I wonder if they would be necessary if we supported
algebraic types, since you could define an "enum" as a virtual type:

const MONDAY = 0;
const TUESDAY = 1;
const WEDNESDAY = 2;
const THURSDAY = 3;
const FRIDAY = 4;
use MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY as WEEKDAY;

function foo(WEEKDAY $day) {
 // must be an integer 0-4, or castable to 0-4 unless strict_types is on.
}

Just a thought...

Anthony



Thats the kind of functionality I would expect from enums, but having a 
dedicated syntax for it would be better for code organization and 
documentation. Is much better to document:


/**
 * Days of the week for blah blah.
 */
enum Weekday {...}

Its purpose would be much clear than documenting this:

use MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY as WEEKDAY;

Also documentation generators like phpdocumentor or apigen could 
generate a list of enum declarations with its descriptions and values. 
Also when type hinting a function parameter like in your example it can 
be a link to the enum definition on documentation.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Rowan Collins]

Bob Weinand wrote on 18/09/2015 15:23:

Well, I think we should*either*  have an ordinal*or*  a name.
But not both.

Currently, after thinking about it, I'm in favor of just a name. And no ordinal.
Having both is, I think, unnecessary.


Yeah, that was my instinct. It's a bit like surrogate keys on database 
tables - if your table has a natural Primary Key, there's no need to add 
an auto-increment field. :)


And the name kind of has to exist anyway, or you can't reference the 
enum value at all. You could make it inaccessible, but then not being 
able to get a string representation for debugging, or to do a dynamic 
Weekdays::getByName($_GET['day']), would be annoying.


Regards,
--
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Let's discuss enums!

[Anthony Ferrara]

Levi et al,

On Fri, Sep 18, 2015 at 10:11 AM, Levi Morrison  wrote:
> On Thu, Sep 17, 2015 at 5:52 PM, John Bafford  wrote:
>> On Sep 17, 2015, at 19:16, Bob Weinand  wrote:
>>>
 Am 18.09.2015 um 01:06 schrieb Rowan Collins :

 This has come up in passing a few times recently, but I'm not sure there's 
 ever been a dedicated discussion of it: would it be useful for PHP to have 
 a built-in Enumeration type, and if so, how should it look?
>>>
>>> I like enums in general, but I'd like to note that there's already a RFC in 
>>> draft by Levi:
>>>
>>> https://wiki.php.net/rfc/enum 
>>>
>>> As far as I know, the RFC is already fairly final and just lacks an 
>>> implementation.
>>>
>>> So, I'd consider bikeshedding an actual RFC first.
>>
>>
>> If we’re bikeshedding, one feature I would really like to see, with 
>> typehinting, is warnings if all cases of an enum aren’t handled in a switch. 
>> So, for example, given our example Weekdays enum, if I wrote this code:
>>
>> switch(Weekday $someWeekday) {
>> case Weekday::MONDAY: break;
>> case Weekday::TUESDAY: break;
>> }
>>
>> By providing the typehint, I’m indicating that I want to get a warning/error 
>> that the switch does not cover all enum values. This would be very handy if 
>> an enum value is added after initial development and someone misses a switch 
>> statement in cleanup.
>>
>> The typehint would also allow generating a warning if someone did something 
>> like
>>
>> switch(Weekday $someWeekday) {
>> //case … all the weekdays: break;
>> case ‘I am not a Weekday’: echo ‘Generate a fatal error here because 
>> string is not a Weekday.’;
>> }
>
> I've looked into this but not in the same syntax you've provided. I
> was exploring a `match` construct that has different semantics:
>
> match ($foo) {
> case Weekday::Monday: {
> echo "Monday";
> } // it is not possible to fall-through with match/case
>
> case Weekday::Tuesday:  echo Monday; // single expression
> doesn't need braces
> } // if it hits the end without a match a runtime error will be emitted
>
> I think this fits into the dynamic behavior of PHP a little better
> than forcing a case for each enum value at compile-time, even if it
> was possible (I suspect it is not).

This is basically pattern matching. And while I'd LOVE to see support
for it in PHP, I think it's a bit off-topic here. Perhaps a new thread
could be opened for it (or ideally a RFC)...?

As far as enums, I wonder if they would be necessary if we supported
algebraic types, since you could define an "enum" as a virtual type:

const MONDAY = 0;
const TUESDAY = 1;
const WEDNESDAY = 2;
const THURSDAY = 3;
const FRIDAY = 4;
use MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY as WEEKDAY;

function foo(WEEKDAY $day) {
// must be an integer 0-4, or castable to 0-4 unless strict_types is on.
}

Just a thought...

Anthony

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Bob Weinand]

> Am 18.09.2015 um 10:42 schrieb Rowan Collins :
> 
> On 18 September 2015 01:15:43 BST, Bob Weinand  wrote:
>> The reason it is not an associative array is that the names are not
>> important.
> ...
>> You never should *rely* on the ordinal value of the enum for anything.
> 
> I feel like I'm missing something here. In my mind, the only absolute 
> universal about all enum implementations is that you refer to values by 
> constant names - e.g. Weekdays::SUNDAY. The name 'SUNDAY' is as fundamental 
> and unchanging as the name 'Weekdays'.
> 
> We rely on names to reference classes and functions all the time, and to 
> serialize properties of an object; so what is it about enums that makes 
> having an integer accessible so important?
> 
> I note that Java does supply an ordinal(), but the docs say you should 
> basically never use it.
> 
> Regards,
> -- 
> Rowan Collins
> [IMSoP]

Well, I think we should *either* have an ordinal *or* a name.
But not both.

Currently, after thinking about it, I'm in favor of just a name. And no ordinal.
Having both is, I think, unnecessary.

Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Levi Morrison]

On Fri, Sep 18, 2015 at 1:05 AM, Pavel Kouřil  wrote:
> On Fri, Sep 18, 2015 at 1:06 AM, Rowan Collins  
> wrote:
>> Hi All,
>>
>> This has come up in passing a few times recently, but I'm not sure there's
>> ever been a dedicated discussion of it: would it be useful for PHP to have a
>> built-in Enumeration type, and if so, how should it look?
>>
>> Many other languages have enum types, with varying functionality. The
>> central concept is always that there's some declared type with a bunch of
>> named constants, but beyond that there's a lot of variability: for starters,
>> is it a type of object, a special way of naming integers, or an uncomparable
>> type more like booleans and nulls?
>>
>>
>> So, what are anyone's thoughts? Am I rambling on too much as usual? ;)
>>
>> Regards,
>>
>> --
>> Rowan Collins
>> [IMSoP]
>>
>
> Hi,
>
> personally, I feel that you should be able to assign numeric value to
> each element (and have them implicit if not specified).
>
> This is imho better for serialization (but it can be done with names
> as well, yeah) - but more importantly, it also allows usage with
> bitwise operators, so you could use them as a "flags" (ie. $weekend =
> Days::SATURDAY | Days::SUNDAY).

In my opinion this is the least valuable form of enums that exists in
any language I am aware of. However I was careful in the RFC to not
prevent this from being a possibility. I would much, much prefer enums
that are more like Rust's, Haskell's or Swift's. It's worth noting
Swift has at least three different kinds of enums, one of which would
allow the kind of behavior you are wanting.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Levi Morrison]

On Thu, Sep 17, 2015 at 5:52 PM, John Bafford  wrote:
> On Sep 17, 2015, at 19:16, Bob Weinand  wrote:
>>
>>> Am 18.09.2015 um 01:06 schrieb Rowan Collins :
>>>
>>> This has come up in passing a few times recently, but I'm not sure there's 
>>> ever been a dedicated discussion of it: would it be useful for PHP to have 
>>> a built-in Enumeration type, and if so, how should it look?
>>
>> I like enums in general, but I'd like to note that there's already a RFC in 
>> draft by Levi:
>>
>> https://wiki.php.net/rfc/enum 
>>
>> As far as I know, the RFC is already fairly final and just lacks an 
>> implementation.
>>
>> So, I'd consider bikeshedding an actual RFC first.
>
>
> If we’re bikeshedding, one feature I would really like to see, with 
> typehinting, is warnings if all cases of an enum aren’t handled in a switch. 
> So, for example, given our example Weekdays enum, if I wrote this code:
>
> switch(Weekday $someWeekday) {
> case Weekday::MONDAY: break;
> case Weekday::TUESDAY: break;
> }
>
> By providing the typehint, I’m indicating that I want to get a warning/error 
> that the switch does not cover all enum values. This would be very handy if 
> an enum value is added after initial development and someone misses a switch 
> statement in cleanup.
>
> The typehint would also allow generating a warning if someone did something 
> like
>
> switch(Weekday $someWeekday) {
> //case … all the weekdays: break;
> case ‘I am not a Weekday’: echo ‘Generate a fatal error here because 
> string is not a Weekday.’;
> }

I've looked into this but not in the same syntax you've provided. I
was exploring a `match` construct that has different semantics:

match ($foo) {
case Weekday::Monday: {
echo "Monday";
} // it is not possible to fall-through with match/case

case Weekday::Tuesday:  echo Monday; // single expression
doesn't need braces
} // if it hits the end without a match a runtime error will be emitted

I think this fits into the dynamic behavior of PHP a little better
than forcing a case for each enum value at compile-time, even if it
was possible (I suspect it is not).

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Rowan Collins]

On 18 September 2015 01:15:43 BST, Bob Weinand  wrote:
>The reason it is not an associative array is that the names are not
>important.
...
>You never should *rely* on the ordinal value of the enum for anything.

I feel like I'm missing something here. In my mind, the only absolute universal 
about all enum implementations is that you refer to values by constant names - 
e.g. Weekdays::SUNDAY. The name 'SUNDAY' is as fundamental and unchanging as 
the name 'Weekdays'.

We rely on names to reference classes and functions all the time, and to 
serialize properties of an object; so what is it about enums that makes having 
an integer accessible so important?

I note that Java does supply an ordinal(), but the docs say you should 
basically never use it.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Let's discuss enums!

[Pavel Kouřil]

On Fri, Sep 18, 2015 at 1:06 AM, Rowan Collins  wrote:
> Hi All,
>
> This has come up in passing a few times recently, but I'm not sure there's
> ever been a dedicated discussion of it: would it be useful for PHP to have a
> built-in Enumeration type, and if so, how should it look?
>
> Many other languages have enum types, with varying functionality. The
> central concept is always that there's some declared type with a bunch of
> named constants, but beyond that there's a lot of variability: for starters,
> is it a type of object, a special way of naming integers, or an uncomparable
> type more like booleans and nulls?
>
>
> So, what are anyone's thoughts? Am I rambling on too much as usual? ;)
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>

Hi,

personally, I feel that you should be able to assign numeric value to
each element (and have them implicit if not specified).

This is imho better for serialization (but it can be done with names
as well, yeah) - but more importantly, it also allows usage with
bitwise operators, so you could use them as a "flags" (ie. $weekend =
Days::SATURDAY | Days::SUNDAY).

Regards
Pavel Kouřil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Ben Scholzen]

On 18.09.2015 01:06, Rowan Collins wrote:

Hi All,

This has come up in passing a few times recently, but I'm not sure
there's ever been a dedicated discussion of it: would it be useful for
PHP to have a built-in Enumeration type, and if so, how should it look?


For what it's worth, there's SplEnum ;)

--
Ben Scholzen
http://www.dasprids.de



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PHP-DEV] Let's discuss enums!

[John Bafford]

> On Sep 17, 2015, at 20:15, Bob Weinand  wrote:
> 
>> Am 18.09.2015 um 01:56 schrieb Rowan Collins :
>> 
>> On 18/09/2015 00:16, Marcio Almada wrote:
>>> A kitten is working on thathttps://wiki.php.net/rfc/enum. Many points
>>> on the linked RFC are compatible to the points you raised so it might
>>> be worth reading before even starting any new proposal.
>> 
>> Aha, I hadn't seen that, should have thought to search the wiki. Still, 
>> interesting that we seems to mostly agree on the key decisions, although 
>> I've gone into more detail about things that he's left as Future Scope, 
>> which is fair enough.
>> 
>> The main thing I'd change if I was writing it is the implicit "ordinal" 
>> property; I don't really see the point of insisting that the order I write 
>> "Red, Green, Blue" has some meaning. On the other hand, I'd give much more 
>> prominence to the name, e.g. by making values() return an associative array. 
>> You're much more likely to want to say "the value whose name is 'RED'" than 
>> "the value I defined first in the list", IMHO.
>> 
>> If you have some kind of initialiser syntax for the values - with or without 
>> a constructor - you get to have ordinals or explicit values (like the Flags 
>> example) if you want them, and just names if not:
>> 
>> enum RenewalAction{
>>   Deny( 0 ),
>>   Approve( 1 );
>> 
>>   public $ordinal;
>> }
>> enum Flags{
>>   a (1  <<  0),
>>   b( 1  <<  1),
>>   c(  1  <<  2),
>>   d(  1  <<  3 ); public $value; }
>> 
>> enum PimaryColours { RED, GREEN, BLUE }
>> 
>> Regards,
>> 
>> -- 
>> Rowan Collins
>> [IMSoP]
> 
> The reason it is not an associative array is that the names are not important.
> 
> But we actually need ordinal(), else we'll end up writing 
> array_search(TheEnum::values(), $value).
> It's mainly important for the purpose of serializing/unserializing (manually 
> or internally).
> 
> You never should *rely* on the ordinal value of the enum for anything. Enums 
> are supposed to be value-less. It's a type. It's not a value. The only usage 
> of the value is going external.
> 
> Also, I honestly think the Flags example is a bad one. (At least as long as 
> we don't have a possibility to typehint combined enums...). If you need that, 
> use class constants. They provide exactly what you need.
> 
> Bob

Besides providing serialization mapping (or, the equivalent of a __toString() 
value if the enum is used in a strong context), an important benefit to 
providing a value for enums would be to allow for changing or deprecating 
enums. So you might want to say something like:

enum FormEvents {
PRE_SUBMIT,
PRE_BIND = PRE_SUBMIT, //deprecated name, provide mapping to new name
}

Another good reason for wanting to provide values is so that you could write 
code like this:

$eventHandlers = [
FormEvents::PRE_SUBMIT => function() { … },
FormEvents::POST_SUBMIT => function() { … },
...
];

Although maybe the ideal solution here would be to allow for array indexes to 
have more types than just int and string (so that the array index actually is 
the enum, not some serialized representation).

-John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Bob Weinand]

> Am 18.09.2015 um 02:35 schrieb John Bafford :
> 
>> On Sep 17, 2015, at 20:06, Bob Weinand  wrote:
>> 
>>> Am 18.09.2015 um 01:52 schrieb John Bafford :
>>> 
>>> If we’re bikeshedding, one feature I would really like to see, with 
>>> typehinting, is warnings if all cases of an enum aren’t handled in a 
>>> switch. So, for example, given our example Weekdays enum, if I wrote this 
>>> code:
>>> 
>>> switch(Weekday $someWeekday) {
>>> case Weekday::MONDAY: break;
>>> case Weekday::TUESDAY: break;
>>> }
>>> 
>>> By providing the typehint, I’m indicating that I want to get a 
>>> warning/error that the switch does not cover all enum values. This would be 
>>> very handy if an enum value is added after initial development and someone 
>>> misses a switch statement in cleanup.
>>> 
>>> The typehint would also allow generating a warning if someone did something 
>>> like
>>> 
>>> switch(Weekday $someWeekday) {
>>> //case … all the weekdays: break;
>>> case ‘I am not a Weekday’: echo ‘Generate a fatal error here because 
>>> string is not a Weekday.’;
>>> }
>> 
>> So, you mean like an implicit
>> default: throw Error("Unhandled enum value Weekday::FRIDAY");
>> 
>> Possible, but then you also just can add
>> default: assert(0);
>> instead of a typehint.
>> 
>> At compile-time won't be really possible, as, when the switch is 
>> encountered, the enum might not yet have been loaded. That's one of the 
>> consequences of PHP's lazy inclusion system...
> 
> Compile-time might not be possible, true, but at least this would provide for 
> runtime checks, and the benefit of explicitly stating intention is that 
> intention is explicitly stated. Also, it would allow the sort of errors I’m 
> proposing be generated to all be standardized across all applications, which 
> would allow fancy error handlers, such as with Symfony, to offer helpful 
> context-specific suggestions. Also, it’d provide static analyzers additional 
> information by which to provide correctness alerts.
> 
> -John

Static analyzers etc. all can look at the cases and conclude that the type 
indeed should have been of a certain Enum. I don't really see a particular 
advantage here.

And for the run-time checks, just add a default: assert(0); as said. I don't 
see loads of benefits from this extra syntax.
Also, as said, I'd pretty much prefer that to be separated out in a different 
RFC as it isn't crucial to the Enum feature itself.

Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Bob Weinand]

> Am 18.09.2015 um 02:27 schrieb Ryan Pallas :
> 
> I few questions wrt the rfc: https://wiki.php.net/rfc/enum
> 
>> An enum value is only equal to itself.
> I'm not sure I agree. How then do I store the enum into a DB and compare it
> after reading?
> switch($db->query('select role from user where user_id = 123')->fetch()[0])
> {
>  case UserRole::Admin:
>  include 'admin.php';
>  break;
>  case UserRole::User;
>  include 'user.php';
>  break;
>  default:
>  include 'login.php';
>  break;
> }
> Would this not ALWAYS include login if UserRole is an enum (instead of a
> final class with constants as I use now, which a switch like this will work
> for)?  Is this only possible with the magic value method? In which case I'd
> have to check the value method, something like case
> UserRole::Admin->ordinal() (or name, or value or whatever)?

You could use UserRole::values()[$ordinal] and then compare against that.

>> This means that if the name enum is used for a property, function,
> method, class, trait or interface there will now be a parse error instead.
> Surely, a property can be named enum, since it can be named other reserved
> words, for example?
> $ php
>  class Foo {
>  public $function = 'callMe';
>  public $trait = 'useMe';
>  public $class = 'instantiateMe';
> }
> $f = new Foo();
> var_dump(get_object_vars($f));
> 
> array(3) {
>  'function' =>
>  string(6) "callMe"
>  'trait' =>
>  string(5) "useMe"
>  'class' =>
>  string(13) "instantiateMe"
> }

Obvious mistake in the RFC, I just changed it...

> Also, I really like the idea of being able to type hint the enum in the
> switch(UserRole) that was mentioned. Not sure I like the idea of an
> implicit throw though, consider the UserRole above, I might have 10
> different roles, but the current switch is only valid for 5 of those roles.
> In this situation, if I add a default: return Auth::NotAuthorized; will
> that supress the implicit fall throw? If so, how often will the implicit
> throw really be hit? I know we have standards that all case statements must
> have default statements, to make sure every case is handled, whether we
> foresaw it or not.

I'd really put that under Future Scope through. It's not really important to 
the feature of Enums themselves and always can be added later on.

Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[John Bafford]

> On Sep 17, 2015, at 20:06, Bob Weinand  wrote:
> 
>> Am 18.09.2015 um 01:52 schrieb John Bafford :
>> 
>> If we’re bikeshedding, one feature I would really like to see, with 
>> typehinting, is warnings if all cases of an enum aren’t handled in a switch. 
>> So, for example, given our example Weekdays enum, if I wrote this code:
>> 
>> switch(Weekday $someWeekday) {
>>  case Weekday::MONDAY: break;
>>  case Weekday::TUESDAY: break;
>> }
>> 
>> By providing the typehint, I’m indicating that I want to get a warning/error 
>> that the switch does not cover all enum values. This would be very handy if 
>> an enum value is added after initial development and someone misses a switch 
>> statement in cleanup.
>> 
>> The typehint would also allow generating a warning if someone did something 
>> like
>> 
>> switch(Weekday $someWeekday) {
>>  //case … all the weekdays: break;
>>  case ‘I am not a Weekday’: echo ‘Generate a fatal error here because 
>> string is not a Weekday.’;
>> }
> 
> So, you mean like an implicit
> default: throw Error("Unhandled enum value Weekday::FRIDAY");
> 
> Possible, but then you also just can add
> default: assert(0);
> instead of a typehint.
> 
> At compile-time won't be really possible, as, when the switch is encountered, 
> the enum might not yet have been loaded. That's one of the consequences of 
> PHP's lazy inclusion system...

Compile-time might not be possible, true, but at least this would provide for 
runtime checks, and the benefit of explicitly stating intention is that 
intention is explicitly stated. Also, it would allow the sort of errors I’m 
proposing be generated to all be standardized across all applications, which 
would allow fancy error handlers, such as with Symfony, to offer helpful 
context-specific suggestions. Also, it’d provide static analyzers additional 
information by which to provide correctness alerts.

-John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Ryan Pallas]

I few questions wrt the rfc: https://wiki.php.net/rfc/enum

> An enum value is only equal to itself.
I'm not sure I agree. How then do I store the enum into a DB and compare it
after reading?
switch($db->query('select role from user where user_id = 123')->fetch()[0])
{
  case UserRole::Admin:
  include 'admin.php';
  break;
  case UserRole::User;
  include 'user.php';
  break;
  default:
  include 'login.php';
  break;
}
Would this not ALWAYS include login if UserRole is an enum (instead of a
final class with constants as I use now, which a switch like this will work
for)?  Is this only possible with the magic value method? In which case I'd
have to check the value method, something like case
UserRole::Admin->ordinal() (or name, or value or whatever)?

>  This means that if the name enum is used for a property, function,
method, class, trait or interface there will now be a parse error instead.
Surely, a property can be named enum, since it can be named other reserved
words, for example?
$ php

  string(6) "callMe"
  'trait' =>
  string(5) "useMe"
  'class' =>
  string(13) "instantiateMe"
}


Also, I really like the idea of being able to type hint the enum in the
switch(UserRole) that was mentioned. Not sure I like the idea of an
implicit throw though, consider the UserRole above, I might have 10
different roles, but the current switch is only valid for 5 of those roles.
In this situation, if I add a default: return Auth::NotAuthorized; will
that supress the implicit fall throw? If so, how often will the implicit
throw really be hit? I know we have standards that all case statements must
have default statements, to make sure every case is handled, whether we
foresaw it or not.

Re: [PHP-DEV] Let's discuss enums!

[Bob Weinand]

> Am 18.09.2015 um 01:56 schrieb Rowan Collins :
> 
> On 18/09/2015 00:16, Marcio Almada wrote:
>> A kitten is working on thathttps://wiki.php.net/rfc/enum. Many points
>> on the linked RFC are compatible to the points you raised so it might
>> be worth reading before even starting any new proposal.
> 
> Aha, I hadn't seen that, should have thought to search the wiki. Still, 
> interesting that we seems to mostly agree on the key decisions, although I've 
> gone into more detail about things that he's left as Future Scope, which is 
> fair enough.
> 
> The main thing I'd change if I was writing it is the implicit "ordinal" 
> property; I don't really see the point of insisting that the order I write 
> "Red, Green, Blue" has some meaning. On the other hand, I'd give much more 
> prominence to the name, e.g. by making values() return an associative array. 
> You're much more likely to want to say "the value whose name is 'RED'" than 
> "the value I defined first in the list", IMHO.
> 
> If you have some kind of initialiser syntax for the values - with or without 
> a constructor - you get to have ordinals or explicit values (like the Flags 
> example) if you want them, and just names if not:
> 
> enum RenewalAction{
>Deny( 0 ),
>Approve( 1 );
> 
>public $ordinal;
> }
> enum Flags{
>a (1  <<  0),
>b( 1  <<  1),
>c(  1  <<  2),
>d(  1  <<  3 ); public $value; }
> 
> enum PimaryColours { RED, GREEN, BLUE }
> 
> Regards,
> 
> -- 
> Rowan Collins
> [IMSoP]

The reason it is not an associative array is that the names are not important.

But we actually need ordinal(), else we'll end up writing 
array_search(TheEnum::values(), $value).
It's mainly important for the purpose of serializing/unserializing (manually or 
internally).

You never should *rely* on the ordinal value of the enum for anything. Enums 
are supposed to be value-less. It's a type. It's not a value. The only usage of 
the value is going external.

Also, I honestly think the Flags example is a bad one. (At least as long as we 
don't have a possibility to typehint combined enums...). If you need that, use 
class constants. They provide exactly what you need.

Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Bob Weinand]

> Am 18.09.2015 um 01:52 schrieb John Bafford :
> 
> On Sep 17, 2015, at 19:16, Bob Weinand  wrote:
>> 
>>> Am 18.09.2015 um 01:06 schrieb Rowan Collins :
>>> 
>>> This has come up in passing a few times recently, but I'm not sure there's 
>>> ever been a dedicated discussion of it: would it be useful for PHP to have 
>>> a built-in Enumeration type, and if so, how should it look?
>> 
>> I like enums in general, but I'd like to note that there's already a RFC in 
>> draft by Levi:
>> 
>> https://wiki.php.net/rfc/enum 
>> 
>> As far as I know, the RFC is already fairly final and just lacks an 
>> implementation.
>> 
>> So, I'd consider bikeshedding an actual RFC first.
> 
> If we’re bikeshedding, one feature I would really like to see, with 
> typehinting, is warnings if all cases of an enum aren’t handled in a switch. 
> So, for example, given our example Weekdays enum, if I wrote this code:
> 
> switch(Weekday $someWeekday) {
>   case Weekday::MONDAY: break;
>   case Weekday::TUESDAY: break;
> }
> 
> By providing the typehint, I’m indicating that I want to get a warning/error 
> that the switch does not cover all enum values. This would be very handy if 
> an enum value is added after initial development and someone misses a switch 
> statement in cleanup.
> 
> The typehint would also allow generating a warning if someone did something 
> like
> 
> switch(Weekday $someWeekday) {
>   //case … all the weekdays: break;
>   case ‘I am not a Weekday’: echo ‘Generate a fatal error here because 
> string is not a Weekday.’;
> }
> 
> -John

So, you mean like an implicit
default: throw Error("Unhandled enum value Weekday::FRIDAY");

Possible, but then you also just can add
default: assert(0);
instead of a typehint.

At compile-time won't be really possible, as, when the switch is encountered, 
the enum might not yet have been loaded. That's one of the consequences of 
PHP's lazy inclusion system...

Bob


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Rowan Collins]

On 18/09/2015 00:16, Marcio Almada wrote:

A kitten is working on thathttps://wiki.php.net/rfc/enum. Many points
on the linked RFC are compatible to the points you raised so it might
be worth reading before even starting any new proposal.


Aha, I hadn't seen that, should have thought to search the wiki. Still, 
interesting that we seems to mostly agree on the key decisions, although 
I've gone into more detail about things that he's left as Future Scope, 
which is fair enough.


The main thing I'd change if I was writing it is the implicit "ordinal" 
property; I don't really see the point of insisting that the order I 
write "Red, Green, Blue" has some meaning. On the other hand, I'd give 
much more prominence to the name, e.g. by making values() return an 
associative array. You're much more likely to want to say "the value 
whose name is 'RED'" than "the value I defined first in the list", IMHO.


If you have some kind of initialiser syntax for the values - with or 
without a constructor - you get to have ordinals or explicit values 
(like the Flags example) if you want them, and just names if not:


enum RenewalAction{
Deny( 0 ),
Approve( 1 );

public $ordinal;
}
enum Flags{
a (1  <<  0),
b( 1  <<  1),
c(  1  <<  2),
d(  1  <<  3 ); public $value; }

enum PimaryColours { RED, GREEN, BLUE }

Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[John Bafford]

On Sep 17, 2015, at 19:16, Bob Weinand  wrote:
> 
>> Am 18.09.2015 um 01:06 schrieb Rowan Collins :
>> 
>> This has come up in passing a few times recently, but I'm not sure there's 
>> ever been a dedicated discussion of it: would it be useful for PHP to have a 
>> built-in Enumeration type, and if so, how should it look?
> 
> I like enums in general, but I'd like to note that there's already a RFC in 
> draft by Levi:
> 
> https://wiki.php.net/rfc/enum 
> 
> As far as I know, the RFC is already fairly final and just lacks an 
> implementation.
> 
> So, I'd consider bikeshedding an actual RFC first.


If we’re bikeshedding, one feature I would really like to see, with 
typehinting, is warnings if all cases of an enum aren’t handled in a switch. 
So, for example, given our example Weekdays enum, if I wrote this code:

switch(Weekday $someWeekday) {
case Weekday::MONDAY: break;
case Weekday::TUESDAY: break;
}

By providing the typehint, I’m indicating that I want to get a warning/error 
that the switch does not cover all enum values. This would be very handy if an 
enum value is added after initial development and someone misses a switch 
statement in cleanup.

The typehint would also allow generating a warning if someone did something like

switch(Weekday $someWeekday) {
//case … all the weekdays: break;
case ‘I am not a Weekday’: echo ‘Generate a fatal error here because 
string is not a Weekday.’;
}

-John


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Marcio Almada]

Hi,

2015-09-17 20:06 GMT-03:00 Rowan Collins :
> Hi All,
>
> This has come up in passing a few times recently, but I'm not sure there's
> ever been a dedicated discussion of it: would it be useful for PHP to have a
> built-in Enumeration type, and if so, how should it look?
>
> Many other languages have enum types, with varying functionality. The
> central concept is always that there's some declared type with a bunch of
> named constants, but beyond that there's a lot of variability: for starters,
> is it a type of object, a special way of naming integers, or an uncomparable
> type more like booleans and nulls?
>
>
> Here are my thoughts on what I'd like from a PHP enum - I'm not using
> "should" in a particularly strong sense, it's just a way of framing the
> points of discussion:
>
> 1) enums should act like values, not mutable objects; an array-style
> copy-on-write behaviour would be possible, but it feels wrong to me to store
> any state in an enum variable, so just plain immutable would be my
> preference
>
> 2) the members of an enum should have a name which is accesible as a string,
> e.g. Weekdays::SUNDAY->getName() == 'SUNDAY'
>
> 3) there should be no accessible "value" for a member; the value of
> Weekdays::SUNDAY is simply Weekdays::SUNDAY, not 0 or 7 or 'SUNDAY' (I'm
> thinking that internally, each member would be represented as an object
> pointer, so there's no real benefit to forcing people to number everything
> like some languages do)
>
> 4) each enum member should be considered a singleton, in the sense that you
> can't construct or destroy one, only reference them; all possible instances
> would be created as soon as the enum was defined
>
> 5) following from (3) and (4), an enum value should compare equal only to
> itself, unlike in C# for instance, where it would be comparable to an
> integer based on its numeric value; similarly it shouldn't be possible to
> cast to or from an enum
>
> 6) an enum should be able to have additional fields; these would be
> initialised in the enum's definition; this is inspired by Java and Python's
> ability to pass parameters to the "constructor" of the enum, but it feels
> weird to me for any logic to happen in that constructor other than simple
> assignments, so I'm thinking of a simpler syntax and implementation. It also
> simplifies immutability if no userland code ever writes to the properties.
> There may be an important use case for constructor logic I'm missing though?
>
> 7) an enum should have default static methods for accessing all the members
> of the enum as an associative array
>
> 8) enums should be a first-class type, is_object(Weekdays::SUNDAY) should
> return false, for instance; maybe Weekdays::SUNDAY instanceof Weekdays
> should return true though
>
> 9) additional static and instance methods should be definable, bearing in
> mind the immutability constraints already discussed
>
>
> Given the above, I think we might end up with something like this:
>
> enum Weekdays {
> member MONDAY; // if there are no fields to initalise, the member just
> needs its name declaring
> member TUESDAY ( 2, 'Chewsdae' ); // positional arguments for populating
> fields in the order they are defined; a bit like Java, but without the
> constructor
> member WEDNESDAY { $dayNumber = 3, $sillyName = 'Wed Nose Day' }; // or
> maybe a named-parameter syntax to make things clearer
> member THURSDAY, FRIDAY, SATURDAY, SUNDAY; // don't force people to
> write each entry on its own line; maybe even the "member" keyword is too
> much?
>
> public $dayNumber, $sillyName; // fields initialised for each member
>
> public static function getWeekend() {
>  return [ self::SATURDAY, self::SUNDAY ];
> }
>
> public function getZeroIndexedDayNumber() {
>  return $this->dayNumber - 1;
> }
> }
>
> $today = Weekdays::THURSDAY;
> foreach ( Weekdays::getMembers() as $day_name => $day ) {
> echo $day->dayNumber;
> if ( $day == $today ) {
>echo "Today!";
> } else {
>echo $day_name; // equivalently: echo $day->getName();
> }
> }
>
> // Do we need a static method to access a member by name, or is this good
> enough?
> $favourite_day = Weekdays::getMembers()[ $_GET['fav_day'] ];
>
> So, what are anyone's thoughts? Am I rambling on too much as usual? ;)
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>

A kitten is working on that https://wiki.php.net/rfc/enum. Many points
on the linked RFC are compatible to the points you raised so it might
be worth reading before even starting any new proposal.

Regards,
Márcio

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

[Bob Weinand]

> Am 18.09.2015 um 01:06 schrieb Rowan Collins :
> 
> Hi All,
> 
> This has come up in passing a few times recently, but I'm not sure there's 
> ever been a dedicated discussion of it: would it be useful for PHP to have a 
> built-in Enumeration type, and if so, how should it look?
> 
> Many other languages have enum types, with varying functionality. The central 
> concept is always that there's some declared type with a bunch of named 
> constants, but beyond that there's a lot of variability: for starters, is it 
> a type of object, a special way of naming integers, or an uncomparable type 
> more like booleans and nulls?
> 
> 
> Here are my thoughts on what I'd like from a PHP enum - I'm not using 
> "should" in a particularly strong sense, it's just a way of framing the 
> points of discussion:
> 
> 1) enums should act like values, not mutable objects; an array-style 
> copy-on-write behaviour would be possible, but it feels wrong to me to store 
> any state in an enum variable, so just plain immutable would be my preference
> 
> 2) the members of an enum should have a name which is accesible as a string, 
> e.g. Weekdays::SUNDAY->getName() == 'SUNDAY'
> 
> 3) there should be no accessible "value" for a member; the value of 
> Weekdays::SUNDAY is simply Weekdays::SUNDAY, not 0 or 7 or 'SUNDAY' (I'm 
> thinking that internally, each member would be represented as an object 
> pointer, so there's no real benefit to forcing people to number everything 
> like some languages do)
> 
> 4) each enum member should be considered a singleton, in the sense that you 
> can't construct or destroy one, only reference them; all possible instances 
> would be created as soon as the enum was defined
> 
> 5) following from (3) and (4), an enum value should compare equal only to 
> itself, unlike in C# for instance, where it would be comparable to an integer 
> based on its numeric value; similarly it shouldn't be possible to cast to or 
> from an enum
> 
> 6) an enum should be able to have additional fields; these would be 
> initialised in the enum's definition; this is inspired by Java and Python's 
> ability to pass parameters to the "constructor" of the enum, but it feels 
> weird to me for any logic to happen in that constructor other than simple 
> assignments, so I'm thinking of a simpler syntax and implementation. It also 
> simplifies immutability if no userland code ever writes to the properties. 
> There may be an important use case for constructor logic I'm missing though?
> 
> 7) an enum should have default static methods for accessing all the members 
> of the enum as an associative array
> 
> 8) enums should be a first-class type, is_object(Weekdays::SUNDAY) should 
> return false, for instance; maybe Weekdays::SUNDAY instanceof Weekdays should 
> return true though
> 
> 9) additional static and instance methods should be definable, bearing in 
> mind the immutability constraints already discussed
> 
> 
> Given the above, I think we might end up with something like this:
> 
> enum Weekdays {
>member MONDAY; // if there are no fields to initalise, the member just 
> needs its name declaring
>member TUESDAY ( 2, 'Chewsdae' ); // positional arguments for populating 
> fields in the order they are defined; a bit like Java, but without the 
> constructor
>member WEDNESDAY { $dayNumber = 3, $sillyName = 'Wed Nose Day' }; // or 
> maybe a named-parameter syntax to make things clearer
>member THURSDAY, FRIDAY, SATURDAY, SUNDAY; // don't force people to write 
> each entry on its own line; maybe even the "member" keyword is too much?
> 
>public $dayNumber, $sillyName; // fields initialised for each member
> 
>public static function getWeekend() {
> return [ self::SATURDAY, self::SUNDAY ];
>}
> 
>public function getZeroIndexedDayNumber() {
> return $this->dayNumber - 1;
>}
> }
> 
> $today = Weekdays::THURSDAY;
> foreach ( Weekdays::getMembers() as $day_name => $day ) {
>echo $day->dayNumber;
>if ( $day == $today ) {
>   echo "Today!";
>} else {
>   echo $day_name; // equivalently: echo $day->getName();
>}
> }
> 
> // Do we need a static method to access a member by name, or is this good 
> enough?
> $favourite_day = Weekdays::getMembers()[ $_GET['fav_day'] ];
> 
> So, what are anyone's thoughts? Am I rambling on too much as usual? ;)
> 
> Regards,
> 
> -- 
> Rowan Collins
> [IMSoP]

I like enums in general, but I'd like to note that there's already a RFC in 
draft by Levi:

https://wiki.php.net/rfc/enum 

As far as I know, the RFC is already fairly final and just lacks an 
implementation.

So, I'd consider bikeshedding an actual RFC first.

Bob