Talk:Requests for comment/Typesafe enums

Looking forward to using it!
That's a really solid proposal and code. The only suggestions I have are:
 * Don't worry about the "final" class tags, it doesn't really belong in the reference implementation. Developers know they can use final if they really want, and it's a bit distracting from your point.
 * Maybe add more basic language constructs to the unit tests to dispel any potential anxiety. For example, in_array, array_search, and switch.

Can I also say, that is some really clean code? Adamw (talk) 21:26, 16 May 2014 (UTC)


 * Done, and done. And thanks! AGreen (WMF) (talk) 18:01, 18 May 2014 (UTC)

Database Safety
Since there is no guarantee that the internal values will remain the same, how would one store an enum value in a database? Doing so as a string is not desirable since string indicies are large and inefficient compared to integer indicies. (I think what I'm trying to get at is that there should be some way of explicitly specifying an integer per enum 'constant'.) Mwalker (WMF) (talk) 23:00, 16 May 2014 (UTC)


 * Yeah, that makes a lot of sense! I'm sure it's doable, I think we just have to figure out the best way to do it. Here are some considerations: the definition and usage should be compact and intuitive, and it should be coherent with and/or reuse other more general facilities that we may add.


 * Also, if you have a some specific use cases, just to have some concrete example code to stare at, that'd be great. Thanks! AGreen (WMF) (talk) 18:01, 18 May 2014 (UTC)

Bitmask Enums
Sometimes it's nice to have a bitmask as an enum; it would be really cool if those could be automatically generated too in some sort of database safe fashion. Mwalker (WMF) (talk) 23:29, 16 May 2014 (UTC)


 * Agreed. See my response under, I'd say basically the same thing on this. AGreen (WMF) (talk) 18:01, 18 May 2014 (UTC)

RFC review 2014-05-21
Architecture_meetings/RFC_review_2014-05-21

tl;dr Will benchmark setup and access. No objections noted to the features requested above. Possible additional use cases mentioned. AGreen (WMF) (talk) 02:59, 22 May 2014 (UTC)

Violates PSR-1
The call to setUp can go in the same .php file as the enum definition.

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md 3rd point

My impression after a quick look
If I had to place a bet on this making code worse or better, it'd unforunately be the fomer. The implementation is rather suspect with the PSR-1 violation and lots of static code. This also reminds me of the GenericArrayObject class I created and put in core, which is not a good thing. What I'd recommend here is that you ask knowledgeable people outside of the MediaWiki community what they think about it. For instance, start a topic on the PHP-FIG list.

--Jeroen De Dauw (talk) 12:37, 22 May 2014 (UTC)