10 ms·

PHP RFC: Enumerations

123 points by jpswade 6y ago

vore 6y ago
What is the "monad-style behavior" they talk about relating to enums here? I really don't understand the connection, and nothing in the rest of the proposal makes any mention of it.
- beberlei 6y ago
  a draft of the RFC contains an example: https://github.com/Crell/enum-comparison/blob/master/rfc.md#maybe https://github.com/Crell/enum-comparison/blob/master/rfc.md#... - I would agree with you that using monad as a term here confuses much more than convinces of the feature.
  - zaphar 6y ago
    The draft there has a feature that the posted RFC does not. Associated types. Without the associated types you can't have the monadic style behavior which is why I was similarly confused by that wording there. Associated types elevates this from "Oh look a C enum" to actually useful ADT's like in Rust or the ML family of languages. I wonder if the draft you linked will make it into the official rfc or not.
    - tored 6y ago
      There is meta RFC for enums https://wiki.php.net/rfc/adts https://wiki.php.net/rfc/adts That links to this rfc https://wiki.php.net/rfc/tagged_unions https://wiki.php.net/rfc/tagged_unions
pdenton 6y ago
> Inside a method on a Case, The $this variable is defined and refers to the Case instance. Say what? Where does this instance come from and what is its scope? > By default, Enumerated Cases have no primitive equivalent. They are simply singleton objects. So, singletons. That way you end up with more global state, with all its consequences. > the following features of objects are not allowed on enumerations: > Enum/Case properties Ok, so these are objects without properties. That could solve the global state problem but at this point you may just as well skip the entire object part as I don't see why exactly it's needed for an identity check. Also, enumerations may have static methods but the provided example says "public function" without the static modifier.
- CiaranMcNulty 6y ago
  >So, singletons. That way you end up with more global state, with all its consequences. As you point out, the lack of properties solves that. The use of a singleton probably relates to the identity issue > at this point you may just as well skip the entire object part as I don't see why exactly it's needed for an identity check. PHP only has 8 types (string, int, bool, float, array, null, resource, object) and they're not likely to be added to (resource is largely deprecated). Given that, object is the only one that's not likely to be abused by relying on the actual scalar value. Keeping it as a singleton ensures that === will still work (it requires 'same instance')
  - pdenton 6y ago
    Thanks for clearing that up. There's one more thing not addressed by the RFC: how to check for a particular enum to exist. The way I see it, a new function "enum_exists" would be needed and validating a QCN would become this ugly: class_exists($qcn) || enum_exists($qcn) || interface_exists($qcn) || trait_exists($qcn)
    - beberlei 6y ago
      its implicitly addressed by saying enums map to objects and clarifying how "::class" works, i.e. enum_exists is not necessary, because its implementation would essentially be class_exists.
      - pdenton 6y ago
        Ah, right. The assumption that "new ReflectionClass($qcn)" where "assert(class_exists($qcn))" works should still be valid as RefelctionEnum[sic] extends ReflectionClass. I'm not completely certain on this, though. If not, it'd definitely break things.
        beberlei 6y ago
        its definitely a weak point of the RFC at the moment.
overflow_error 6y ago
That enum methods cringe me, IMO they should try to make enum as dumb as possible, more like key-value pair, let the class/function handle the implementation details.
codeflo 6y ago
I have to wonder, how big is the overlap between people who understand and want to use algebraic datatypes, and people who program in PHP? PHP’s main selling point has always been its low barrier to entry. Introducing high-level abstractions like ADTs will hurt that user group. At the same time, I don’t think PHP can ever catch up with high-level languages that were built on less shaky foundations (and cleaner syntax). So what’s the end goal here?
- geek_at 6y ago
  > PHP’s main selling point has always been its low barrier to entry While this is 100% true (though latley more true for Python), the people who started using PHP years ago and stuck with it over the years have now gotten the tools for a more precise and structured code base. I personally use PHP even on servers for quick scripting of things because I never learned Python well enough to have all functions at my finger tips and don't get me started on powershell ;D
- darkcrag 6y ago
  JS has taken over the world and I wouldn't say that it has a more or less shaky foundation than PHP. See var.
  - codeflo 6y ago
    You do have a point, I’m not the biggest fan of JS either. But notice that var is linted out of every modern JS codebase. Where’s PHP’s equivalent of let/const? Also, I think a huge part of JS’s staying power was that besides its obvious warts, it always had a solid FP foundation as well. JS was one of the first mainstream languages with full closures. That was a powerful tool for building abstractions right from the start, and I don’t think Node.js would have happened without this.
    - spdionis 6y ago
      Not clear why you think php needs let/const like in js.
    - 6y ago
archi42 6y ago
This is about time, and I like that they can have functions. No stupid enum_too_to_string($bar) calls, just $bar->toString(). When I built a small, internal tool a few years ago, I couldn't believe it still didn't offer something as basic as an enum type. Didn't bother me when I learned PHP4 as a kid, but studying CS and becoming a professional developer really changes what one expects from a language.
- bob_page 6y ago
  This is how I do it, currently: interface Pokemon { public const MissingNo = 0; public const Bulbasaur = 1; /* ... */ public const Slowking = 199; public const Misdreavus = 200; }
- Jach 6y ago
  I think at some point you turn around and become relatively unbothered again. Or you have to if you're forced to work in languages lacking things you like from other languages and don't want to feel frustrated all the time. (Doing Java and JS for years I was able to reduce the frustration to only some of the time.) Until Python 3.4, there were no enums blessed in the reference implementation, but that was fine for me. Is https://docs.python.org/3/library/enum.html https://docs.python.org/3/library/enum.html really that much better than the examples in https://web.archive.org/web/20120207145701/https://norvig.com/python-iaq.html https://web.archive.org/web/20120207145701/https://norvig.co... ? More powerful, sure. But if we just wanted simple C++ enums and not structured Java-like enums it's hard to argue against the conciseness of RED,GREEN,BLUE = range(3) and moving on with what matters. I guess two advantages of having something blessed by the language are 1) you don't need to think anymore or argue about whose workarounds (if any) are better, like the sibling's comment using PHP interfaces with consts inside, and 2) if the language isn't flexible enough to add the thing yourself, if the thing needs privileged status by the compiler or whatever, then you need the blessing for the best experience. My favorite language (Lisp) has no enums, but it's flexible enough to add them (and people have done so) in a way pretty indistinguishable from if they were there from the start, or of course you can use moral equivalents to the Python 2 examples without fuss. (Rather than just variables though there are also keywords or just plain symbols, which you can have type checked with deftype, and dispatch on with object methods if you like structured enums.)
slifin 6y ago
I'm surprised PHPers haven't started noticing that over specifying something can be a problem too Hopefully ADT support should help illustrate that, I had to use F# for a long time to notice that
xd 6y ago
There's a good writeup that looks at a range of other languages implementation of enum, linked at the end of the RFC: https://github.com/Crell/enum-comparison https://github.com/Crell/enum-comparison
mschuster91 6y ago
Oh finally. Hope it gets passed and then picked up by Doctrine real quick, I'm quite sick of writing boilerplate to manually deal with enums.
xellisx 6y ago
I want structs and static classes (OK, the last one isn't really needed, just more about being a stickler).
- tored 6y ago
  Static class is probably the best solution for having namespaced functions combined with having auto loading working correctly. Structs would be great too, especially if PHP could support inner class definitions.
  - xellisx 6y ago
    I started on some RFCs, but due to life events, I don't have time to finish them out. https://github.com/ellisgl/PHP-RFC-Struct-Data-Type https://github.com/ellisgl/PHP-RFC-Struct-Data-Type https://github.com/ellisgl/PHP-RFC-Static-Class-Type https://github.com/ellisgl/PHP-RFC-Static-Class-Type [edit: spelling]
momokoko 6y ago
I find it interesting that as the industry moves closer and closer to smaller, less complex, microservice style codebases, languages are moving in the opposite direction and creating more and more features and complexity designed to help handle large and complex codebases. It’s almost as if language maintainers are removed from the practical applications that their language.
- stephenr 6y ago
  It’s almost as if microservices are a fad and like all fads will be forgotten when the cool kids jump on the next bandwagon.
- stouset 6y ago
  Language features generally solve problems users experience in real projects. Sometimes they do a better or worse job (see C++17 variant/visit in contrast), but the goal is virtually always to turn a larger, difficult-to-understand, complex, or error-prone set of statements into a smaller, easier-to-understand, simpler, resilient set of ones. Complexity that isn’t solved in the language itself inevitably works its way into projects that use it, which is why abstractions and standard libraries exist in the first place.
- dehrmann 6y ago
  The main feature I can think of that helps languages with larger codebases is static typing (Python, Typescript). Prior to Python type annotation, at a previous job, someone commented that Python didn't scale not because of performance, but because as you add more and more developers to a complex codebase, the lack of type safety ad growing codebase made safe changes hard. Over in Java, a lot of the language changes are just syntactic sugar to make Java less verbose. Granted, Jigsaw is an exception, and JVM enhancements are good for everyone.
- deleted 6y ago
  [deleted]
tored 6y ago
Defiantly one of the best proposals for enums in PHP so far. It handles many of the needed requirements, reuses classes as building block so you get a type, can have methods or case specific methods, can implement interfaces, can be mapped to a primitive value and solves the problem with strict equality beautifully. One problem is that an enum can't be an index key of an array. Read why in this reddit thread between the authors of the RFC. https://www.reddit.com/r/PHP/comments/k6w74p/rfc_enums/geo00su/ https://www.reddit.com/r/PHP/comments/k6w74p/rfc_enums/geo00...

123 points by jpswade 6y ago

vore 6y ago

What is the "monad-style behavior" they talk about relating to enums here? I really don't understand the connection, and nothing in the rest of the proposal makes any mention of it.

beberlei 6y ago
a draft of the RFC contains an example: https://github.com/Crell/enum-comparison/blob/master/rfc.md#maybe https://github.com/Crell/enum-comparison/blob/master/rfc.md#... - I would agree with you that using monad as a term here confuses much more than convinces of the feature.
- zaphar 6y ago
  The draft there has a feature that the posted RFC does not. Associated types. Without the associated types you can't have the monadic style behavior which is why I was similarly confused by that wording there. Associated types elevates this from "Oh look a C enum" to actually useful ADT's like in Rust or the ML family of languages. I wonder if the draft you linked will make it into the official rfc or not.
  - tored 6y ago
    There is meta RFC for enums https://wiki.php.net/rfc/adts https://wiki.php.net/rfc/adts That links to this rfc https://wiki.php.net/rfc/tagged_unions https://wiki.php.net/rfc/tagged_unions

pdenton 6y ago

> Inside a method on a Case, The $this variable is defined and refers to the Case instance. Say what? Where does this instance come from and what is its scope? > By default, Enumerated Cases have no primitive equivalent. They are simply singleton objects. So, singletons. That way you end up with more global state, with all its consequences. > the following features of objects are not allowed on enumerations: > Enum/Case properties Ok, so these are objects without properties. That could solve the global state problem but at this point you may just as well skip the entire object part as I don't see why exactly it's needed for an identity check. Also, enumerations may have static methods but the provided example says "public function" without the static modifier.

CiaranMcNulty 6y ago
>So, singletons. That way you end up with more global state, with all its consequences. As you point out, the lack of properties solves that. The use of a singleton probably relates to the identity issue > at this point you may just as well skip the entire object part as I don't see why exactly it's needed for an identity check. PHP only has 8 types (string, int, bool, float, array, null, resource, object) and they're not likely to be added to (resource is largely deprecated). Given that, object is the only one that's not likely to be abused by relying on the actual scalar value. Keeping it as a singleton ensures that === will still work (it requires 'same instance')
- pdenton 6y ago
  Thanks for clearing that up. There's one more thing not addressed by the RFC: how to check for a particular enum to exist. The way I see it, a new function "enum_exists" would be needed and validating a QCN would become this ugly: class_exists($qcn) || enum_exists($qcn) || interface_exists($qcn) || trait_exists($qcn)
  - beberlei 6y ago
    its implicitly addressed by saying enums map to objects and clarifying how "::class" works, i.e. enum_exists is not necessary, because its implementation would essentially be class_exists.
    - pdenton 6y ago
      Ah, right. The assumption that "new ReflectionClass($qcn)" where "assert(class_exists($qcn))" works should still be valid as RefelctionEnum[sic] extends ReflectionClass. I'm not completely certain on this, though. If not, it'd definitely break things.
      - beberlei 6y ago
        its definitely a weak point of the RFC at the moment.

overflow_error 6y ago

That enum methods cringe me, IMO they should try to make enum as dumb as possible, more like key-value pair, let the class/function handle the implementation details.

codeflo 6y ago

I have to wonder, how big is the overlap between people who understand and want to use algebraic datatypes, and people who program in PHP? PHP’s main selling point has always been its low barrier to entry. Introducing high-level abstractions like ADTs will hurt that user group. At the same time, I don’t think PHP can ever catch up with high-level languages that were built on less shaky foundations (and cleaner syntax). So what’s the end goal here?

geek_at 6y ago
> PHP’s main selling point has always been its low barrier to entry While this is 100% true (though latley more true for Python), the people who started using PHP years ago and stuck with it over the years have now gotten the tools for a more precise and structured code base. I personally use PHP even on servers for quick scripting of things because I never learned Python well enough to have all functions at my finger tips and don't get me started on powershell ;D
darkcrag 6y ago
JS has taken over the world and I wouldn't say that it has a more or less shaky foundation than PHP. See var.
- codeflo 6y ago
  You do have a point, I’m not the biggest fan of JS either. But notice that var is linted out of every modern JS codebase. Where’s PHP’s equivalent of let/const? Also, I think a huge part of JS’s staying power was that besides its obvious warts, it always had a solid FP foundation as well. JS was one of the first mainstream languages with full closures. That was a powerful tool for building abstractions right from the start, and I don’t think Node.js would have happened without this.
  - spdionis 6y ago
    Not clear why you think php needs let/const like in js.
  - 6y ago

archi42 6y ago

This is about time, and I like that they can have functions. No stupid enum_too_to_string($bar) calls, just $bar->toString(). When I built a small, internal tool a few years ago, I couldn't believe it still didn't offer something as basic as an enum type. Didn't bother me when I learned PHP4 as a kid, but studying CS and becoming a professional developer really changes what one expects from a language.

bob_page 6y ago
This is how I do it, currently: interface Pokemon { public const MissingNo = 0; public const Bulbasaur = 1; /* ... */ public const Slowking = 199; public const Misdreavus = 200; }
Jach 6y ago
I think at some point you turn around and become relatively unbothered again. Or you have to if you're forced to work in languages lacking things you like from other languages and don't want to feel frustrated all the time. (Doing Java and JS for years I was able to reduce the frustration to only some of the time.) Until Python 3.4, there were no enums blessed in the reference implementation, but that was fine for me. Is https://docs.python.org/3/library/enum.html https://docs.python.org/3/library/enum.html really that much better than the examples in https://web.archive.org/web/20120207145701/https://norvig.com/python-iaq.html https://web.archive.org/web/20120207145701/https://norvig.co... ? More powerful, sure. But if we just wanted simple C++ enums and not structured Java-like enums it's hard to argue against the conciseness of RED,GREEN,BLUE = range(3) and moving on with what matters. I guess two advantages of having something blessed by the language are 1) you don't need to think anymore or argue about whose workarounds (if any) are better, like the sibling's comment using PHP interfaces with consts inside, and 2) if the language isn't flexible enough to add the thing yourself, if the thing needs privileged status by the compiler or whatever, then you need the blessing for the best experience. My favorite language (Lisp) has no enums, but it's flexible enough to add them (and people have done so) in a way pretty indistinguishable from if they were there from the start, or of course you can use moral equivalents to the Python 2 examples without fuss. (Rather than just variables though there are also keywords or just plain symbols, which you can have type checked with deftype, and dispatch on with object methods if you like structured enums.)

slifin 6y ago

I'm surprised PHPers haven't started noticing that over specifying something can be a problem too Hopefully ADT support should help illustrate that, I had to use F# for a long time to notice that

xd 6y ago

There's a good writeup that looks at a range of other languages implementation of enum, linked at the end of the RFC: https://github.com/Crell/enum-comparison https://github.com/Crell/enum-comparison

mschuster91 6y ago

Oh finally. Hope it gets passed and then picked up by Doctrine real quick, I'm quite sick of writing boilerplate to manually deal with enums.

xellisx 6y ago

I want structs and static classes (OK, the last one isn't really needed, just more about being a stickler).

tored 6y ago
Static class is probably the best solution for having namespaced functions combined with having auto loading working correctly. Structs would be great too, especially if PHP could support inner class definitions.
- xellisx 6y ago
  I started on some RFCs, but due to life events, I don't have time to finish them out. https://github.com/ellisgl/PHP-RFC-Struct-Data-Type https://github.com/ellisgl/PHP-RFC-Struct-Data-Type https://github.com/ellisgl/PHP-RFC-Static-Class-Type https://github.com/ellisgl/PHP-RFC-Static-Class-Type [edit: spelling]

momokoko 6y ago

I find it interesting that as the industry moves closer and closer to smaller, less complex, microservice style codebases, languages are moving in the opposite direction and creating more and more features and complexity designed to help handle large and complex codebases. It’s almost as if language maintainers are removed from the practical applications that their language.

stephenr 6y ago
It’s almost as if microservices are a fad and like all fads will be forgotten when the cool kids jump on the next bandwagon.
stouset 6y ago
Language features generally solve problems users experience in real projects. Sometimes they do a better or worse job (see C++17 variant/visit in contrast), but the goal is virtually always to turn a larger, difficult-to-understand, complex, or error-prone set of statements into a smaller, easier-to-understand, simpler, resilient set of ones. Complexity that isn’t solved in the language itself inevitably works its way into projects that use it, which is why abstractions and standard libraries exist in the first place.
dehrmann 6y ago
The main feature I can think of that helps languages with larger codebases is static typing (Python, Typescript). Prior to Python type annotation, at a previous job, someone commented that Python didn't scale not because of performance, but because as you add more and more developers to a complex codebase, the lack of type safety ad growing codebase made safe changes hard. Over in Java, a lot of the language changes are just syntactic sugar to make Java less verbose. Granted, Jigsaw is an exception, and JVM enhancements are good for everyone.
deleted 6y ago
[deleted]

tored 6y ago

Defiantly one of the best proposals for enums in PHP so far. It handles many of the needed requirements, reuses classes as building block so you get a type, can have methods or case specific methods, can implement interfaces, can be mapped to a primitive value and solves the problem with strict equality beautifully. One problem is that an enum can't be an index key of an array. Read why in this reddit thread between the authors of the RFC. https://www.reddit.com/r/PHP/comments/k6w74p/rfc_enums/geo00su/ https://www.reddit.com/r/PHP/comments/k6w74p/rfc_enums/geo00...