One thing I would really like to see in 5.4 is enums.
There is already an RFC for that: https://wiki.php.net/rfc/enum
This was discussed in february this year, but no consensus was reached.
IIRC, the most notable problems were:
- What is the 'value' of enum constant: string or int, user defined scalar,
defaults - Ability to make enums more 'class like', some people wanted to be able to
add methods.
Another thing which was discussed (and I think most people agreed on that),
but is not in the RFC: type hinting in method signatures.
I think we should keep this simple proposal simple, let it be an enum in all
its simplicity.
The toughest part would be to decide what would be the default value. Some
proposed to use the name of the constant, which is imho best for
debuggability (i like this one the best), or an auto incrementing int,
saying that it is better performance wise and which is more analog with
mysql's enum type.
So, to sum up:
- Do we really need enum level methods?
- Need to reach consensus on default values (strings vs auto inc. ints)
- RFC needs to be updated, explaining the type hinting of enums in method
signatures
Regards,
Dennis Haarbrink
So, to sum up:
- Do we really need enum level methods?
- Need to reach consensus on default values (strings vs auto inc. ints)
- RFC needs to be updated, explaining the type hinting of enums in method signatures
I'm wondering if the enum storage would work like an array.
The parallel ...
array('YES', 'NO', 'MAYBE') vs. enum{YES, NO, MAYBE}
In this example, all the keys of the array would be the same as the
values of the enum
array(0 => 'YES', 1 => 'NO', 2 => 'MAYBE') vs. enum(YES = 0, NO = 1, MAYBE = 2}
In both cases, there is a name/value pairing. In both cases an
unassigned key (for the array) or value (for the enum) is
automatically determined.
If a non sequential integer value is used ...
array(2047 => 'E_ALL_PRE_5_2', 6143 => 'E_ALL_5_2', 30719 =>
'E_ALL_5_3') vs enum{E_ALL_PRE_5_2 = 2047, E_ALL_5_2 = 6143, E_ALL_5_3
= 30719}
then this still follows a recognisable pattern of key/value.
If a non numeric key(array) or value(enum) is used, then I think the
enum{} should follow the existing array() rules.
If a mix is used, then there is already a well documented pattern of
behaviour that I think should be followed.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
Hi,
The RFC was supposed to be a draft (i didn't really added it in the good
section) and was written more to introduce the idea and make people think
about it.
Feel free to update it with any idea, concern you may have.
Pierrick
One thing I would really like to see in 5.4 is enums.
There is already an RFC for that: https://wiki.php.net/rfc/enumThis was discussed in february this year, but no consensus was reached.
IIRC, the most notable problems were:
- What is the 'value' of enum constant: string or int, user defined scalar,
defaults- Ability to make enums more 'class like', some people wanted to be able to
add methods.Another thing which was discussed (and I think most people agreed on that),
but is not in the RFC: type hinting in method signatures.I think we should keep this simple proposal simple, let it be an enum in
all
its simplicity.
The toughest part would be to decide what would be the default value. Some
proposed to use the name of the constant, which is imho best for
debuggability (i like this one the best), or an auto incrementing int,
saying that it is better performance wise and which is more analog with
mysql's enum type.So, to sum up:
- Do we really need enum level methods?
- Need to reach consensus on default values (strings vs auto inc. ints)
- RFC needs to be updated, explaining the type hinting of enums in method
signaturesRegards,
Dennis Haarbrink
As soon as I have my requested write permission in the rfc namespace i will
update it.
--
Dennis Haarbrink
2011/6/3 Pierrick Charron pierrick@webstart.fr
Hi,
The RFC was supposed to be a draft (i didn't really added it in the good
section) and was written more to introduce the idea and make people think
about it.
Feel free to update it with any idea, concern you may have.Pierrick
One thing I would really like to see in 5.4 is enums.
There is already an RFC for that: https://wiki.php.net/rfc/enumThis was discussed in february this year, but no consensus was reached.
IIRC, the most notable problems were:
- What is the 'value' of enum constant: string or int, user defined
scalar,
defaults- Ability to make enums more 'class like', some people wanted to be able
to
add methods.Another thing which was discussed (and I think most people agreed on
that),
but is not in the RFC: type hinting in method signatures.I think we should keep this simple proposal simple, let it be an enum in
all
its simplicity.
The toughest part would be to decide what would be the default value. Some
proposed to use the name of the constant, which is imho best for
debuggability (i like this one the best), or an auto incrementing int,
saying that it is better performance wise and which is more analog with
mysql's enum type.So, to sum up:
- Do we really need enum level methods?
- Need to reach consensus on default values (strings vs auto inc. ints)
- RFC needs to be updated, explaining the type hinting of enums in method
signaturesRegards,
Dennis Haarbrink
As soon as I have my requested write permission in the rfc namespace i will
update it.--
Dennis Haarbrink2011/6/3 Pierrick Charronpierrick@webstart.fr
Hi,
The RFC was supposed to be a draft (i didn't really added it in the good
section) and was written more to introduce the idea and make people think
about it.
Feel free to update it with any idea, concern you may have.Pierrick
One thing I would really like to see in 5.4 is enums.
There is already an RFC for that: https://wiki.php.net/rfc/enumThis was discussed in february this year, but no consensus was reached.
IIRC, the most notable problems were:
- What is the 'value' of enum constant: string or int, user defined
scalar,
defaults- Ability to make enums more 'class like', some people wanted to be able
to
add methods.Another thing which was discussed (and I think most people agreed on
that),
but is not in the RFC: type hinting in method signatures.I think we should keep this simple proposal simple, let it be an enum in
all
its simplicity.
The toughest part would be to decide what would be the default value. Some
proposed to use the name of the constant, which is imho best for
debuggability (i like this one the best), or an auto incrementing int,
saying that it is better performance wise and which is more analog with
mysql's enum type.So, to sum up:
- Do we really need enum level methods?
- Need to reach consensus on default values (strings vs auto inc. ints)
- RFC needs to be updated, explaining the type hinting of enums in method
signaturesRegards,
Dennis Haarbrink
If I might raise the question, I am also really interested in how enums
could respond across namespace. Personally, I am not entirely sure about
the ability to add methods to enums. That sounds like a class, to me.
However, the second example on the RFC of use-case, wherein the
developer uses a class to contain constants, sounds to me like a
namespacing issue. Would enums be objects that are within the scope of
the namespace, like classes, or would they be global? I would personally
favor they remain in the scope of the namespace. That removes the need
to prefix them with any sort of pseudo-namespace (like a class, for
example), and it prevents collisions, of course.
- M.
2011/6/3 Marcel Esser marcel.esser@croscon.com
As soon as I have my requested write permission in the rfc namespace i
will
update it.--
Dennis Haarbrink2011/6/3 Pierrick Charronpierrick@webstart.fr
Hi,
The RFC was supposed to be a draft (i didn't really added it in the good
section) and was written more to introduce the idea and make people think
about it.
Feel free to update it with any idea, concern you may have.Pierrick
One thing I would really like to see in 5.4 is enums.
There is already an RFC for that: https://wiki.php.net/rfc/enum
This was discussed in february this year, but no consensus was reached.
IIRC, the most notable problems were:
- What is the 'value' of enum constant: string or int, user defined
scalar,
defaults- Ability to make enums more 'class like', some people wanted to be able
to
add methods.Another thing which was discussed (and I think most people agreed on
that),
but is not in the RFC: type hinting in method signatures.I think we should keep this simple proposal simple, let it be an enum in
all
its simplicity.
The toughest part would be to decide what would be the default value.
Some
proposed to use the name of the constant, which is imho best for
debuggability (i like this one the best), or an auto incrementing int,
saying that it is better performance wise and which is more analog with
mysql's enum type.So, to sum up:
- Do we really need enum level methods?
- Need to reach consensus on default values (strings vs auto inc. ints)
- RFC needs to be updated, explaining the type hinting of enums in
method
signaturesRegards,
Dennis HaarbrinkIf I might raise the question, I am also really interested in how enums
could respond across namespace. Personally, I am not entirely sure about the
ability to add methods to enums. That sounds like a class, to me. However,
the second example on the RFC of use-case, wherein the developer uses a
class to contain constants, sounds to me like a namespacing issue. Would
enums be objects that are within the scope of the namespace, like classes,
or would they be global? I would personally favor they remain in the scope
of the namespace. That removes the need to prefix them with any sort of
pseudo-namespace (like a class, for example), and it prevents collisions, of
course.
- M.
--
I'm also not so sure about inlining an enum in a class. I think they should
always be first class citizens. And as such they adhere to the same
namespace rules as classes.
Maybe Pierrick can clarify his intentions.
--
Dennis Haarbrink
As much as I used enums in C++, I'm not sure that this is really the right tool here, and it often introduces more problems than it solves. Specific concerns that come to mind:
- In C++ this often led to nasty needs such as a "LOG_LEVEL_COUNT" entry at the end of the list of enums.
- Sometimes devs want to add items in the middle of the list for code organization purposes. This silently changes the values of the other constants and it isn't clear when that will or won't break stuff.
- Better than half the time, enums seem to be a series of bit flags, not sequential numbers (in this case enum offers NO value over the current const lists).
- The greatest value of enums in C++ is actually related to typesafety. Admittedly, this was sometimes more of a frustration than a help, but that was really just an implementation issue, not an inherent problem with enums and typesafety.
- There is no clear path for extending the enums through inheritance.
Allowing enums to be (optionally) named would open a clear path to address counts and hinting, but still doesn't address the problems inherent in automatic numbering, and would complicate the inheritance question.
IMHO this should wait until we can address some of these items. Otherwise the feature is just a halfbaked not-so-short shorthand for constants.
John Crenshaw
Priacta, Inc.
2011/6/3 John Crenshaw johncrenshaw@priacta.com
As much as I used enums in C++, I'm not sure that this is really the right
tool here, and it often introduces more problems than it solves. Specific
concerns that come to mind:
- In C++ this often led to nasty needs such as a "LOG_LEVEL_COUNT" entry
at the end of the list of enums.- Sometimes devs want to add items in the middle of the list for code
organization purposes. This silently changes the values of the other
constants and it isn't clear when that will or won't break stuff.- Better than half the time, enums seem to be a series of bit flags, not
sequential numbers (in this case enum offers NO value over the current const
lists).- The greatest value of enums in C++ is actually related to typesafety.
Admittedly, this was sometimes more of a frustration than a help, but that
was really just an implementation issue, not an inherent problem with enums
and typesafety.- There is no clear path for extending the enums through inheritance.
Allowing enums to be (optionally) named would open a clear path to address
counts and hinting, but still doesn't address the problems inherent in
automatic numbering, and would complicate the inheritance question.IMHO this should wait until we can address some of these items. Otherwise
the feature is just a halfbaked not-so-short shorthand for constants.John Crenshaw
Priacta, Inc.--
- I'm not so sure what you mean with that statement
- A very strong argument for using the name of the constant as the default
value
3 and 4: The way I see it, type safety is the only valid argument for
proposing enums
5: I have never felt the need for inheritance in enums. Do you have a use
case for that?
I also think that enums should always be named.
--
Dennis Haarbrink
-
Yeah, let me explain: A lot of times (at least in the patterns that lead to enum usage in C++) you need to be able to know what is in the enum, for example, to iterate a list that will have exactly the same number of entries as the enum or something. In other words, the enum represents something, and often times you need to "enumerate" the enum. In C++, the only DRY way to do this is to add a "*_COUNT" entry as the last enum, which will conveniently result in that entry getting assigned a value equal to the number of entries, so you can do something like for(int i = 0; i < FOO_COUNT; i++) {}. I can't say for sure that we will or won't run into this in PHP, but the nature of enums makes these sorts of patters likely. The fix (I think) is to be able to inspect the enum. Probably need to support count(enumtype), as well as something like enum_ids(enumtype), enum_values(enumtype), and enum_to_array(enumtype).
-
True, name as value is the only solution I see for that, but this would make the behavior radically different from the likely expectation. Sometimes it doesn't matter, but sometimes it will. I have some concern with something that LOOKS like an enum from other languages where enums are integral, but doesn't actually act integral. The other problem with non-integral enums is comparison, which users might expect to work by default. Unless this was implemented as a whole new type internally, comparison would be impossible. Implementing as a new type raises questions about implicit conversion, so that probably won't work.
-
This is heavily connected to the typesafety question. A simple potential PHP example that comes to mind would be the Zend_Log class. This class has a list of priorities, which would make a whole lot of sense to put in an enum. (Incidentally an "enum_to_array()" method would then allow this code to be cleaned up a bit). The log method accepts priority as an argument, so it would be sensible to give this a type hint. The catch is that the class is also designed to allow new priorities to be added later, especially in a derived class, so, I derive a new My_Log class, and want to extend the enum with a couple of additional entries. (I actually worked with some code almost exactly like this just a few days ago). The bottom line here is that enums become a hinderance to inheritance unless they can be extended. If an enum can't be extended, it is effectively final, regardless of whether that is actually helpful.
John Crenshaw
Priacta, Inc.
From: Dennis Haarbrink [mailto:dhaarbrink@gmail.com]
Sent: Friday, June 03, 2011 2:37 PM
To: John Crenshaw
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Enum
2011/6/3 John Crenshaw <johncrenshaw@priacta.commailto:johncrenshaw@priacta.com>
As much as I used enums in C++, I'm not sure that this is really the right tool here, and it often introduces more problems than it solves. Specific concerns that come to mind:
- In C++ this often led to nasty needs such as a "LOG_LEVEL_COUNT" entry at the end of the list of enums.
- Sometimes devs want to add items in the middle of the list for code organization purposes. This silently changes the values of the other constants and it isn't clear when that will or won't break stuff.
- Better than half the time, enums seem to be a series of bit flags, not sequential numbers (in this case enum offers NO value over the current const lists).
- The greatest value of enums in C++ is actually related to typesafety. Admittedly, this was sometimes more of a frustration than a help, but that was really just an implementation issue, not an inherent problem with enums and typesafety.
- There is no clear path for extending the enums through inheritance.
Allowing enums to be (optionally) named would open a clear path to address counts and hinting, but still doesn't address the problems inherent in automatic numbering, and would complicate the inheritance question.
IMHO this should wait until we can address some of these items. Otherwise the feature is just a halfbaked not-so-short shorthand for constants.
John Crenshaw
Priacta, Inc.
--
- I'm not so sure what you mean with that statement
- A very strong argument for using the name of the constant as the default value
3 and 4: The way I see it, type safety is the only valid argument for proposing enums
5: I have never felt the need for inheritance in enums. Do you have a use case for that?
I also think that enums should always be named.
--
Dennis Haarbrink
One thing I would really like to see in 5.4 is enums.
There is already an RFC for that: https://wiki.php.net/rfc/enumThis was discussed in february this year, but no consensus was reached.
IIRC, the most notable problems were:
- What is the 'value' of enum constant: string or int, user defined scalar,
defaults- Ability to make enums more 'class like', some people wanted to be able to
add methods.Another thing which was discussed (and I think most people agreed on that),
but is not in the RFC: type hinting in method signatures.
I'd like to see some examples of using the enums -- how do you
reference them? How do you make comparisons against them? As an example:
if (!$value in SomeEnum) {
throw new Exception;
}
Would that work? or are you envisioning this:
if (!$value instanceof SomeEnum) {
throw new Exception;
}
(The latter is less intuitive, IMO).
One particular use case I'm curious about: could comparisons take into
consideration logical operators (&, |, ^, etc.)?
Comparison and/or type hinting against an enum is really the only
feature I see that makes them worthwhile; otherwise, we already have
namespaced and class-level constants.
I think we should keep this simple proposal simple, let it be an enum in all
its simplicity.
The toughest part would be to decide what would be the default value. Some
proposed to use the name of the constant, which is imho best for
debuggability (i like this one the best), or an auto incrementing int,
saying that it is better performance wise and which is more analog with
mysql's enum type.So, to sum up:
- Do we really need enum level methods?
- Need to reach consensus on default values (strings vs auto inc. ints)
- RFC needs to be updated, explaining the type hinting of enums in method
signatures
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc