Re: [RFC] [Discussion] Add get_declared_enums() function

On Wed, Oct 2, 2024, at 14:27, Alexandru Pătrănescu wrote: > > On Wed, Oct 2, 2024 at 11:06 AM Rob Landers <rob@bottled.codes> wrote: >> __ >> On Wed, Oct 2, 2024, at 09:20, Alexandru Pătrănescu wrote: >>> >>> On Wed, Oct 2, 2024 at 1:48 AM Juliette Reinders Folmer >>> <php-internals_nospam@adviesenzo.nl> wrote: >>>> L.S., >>>> >>>> After the earlier discussion [1] regarding this topic in August, it is our pleasure >>>> to present the RFC to add a get_declared_enums() function to PHP for >>>> discussion. >>>> >>>> https://wiki.php.net/rfc/get_declared_enums >>>> >>>> We look forward to your feedback and hope for a constructive discussion. >>> >>> I'm all for get_declared_enums(). >>> However, I don't accept that enums are not classes and going with the assumption >>> that they are not will bring more problems than it solves. >>> >>> I noticed how you analyzed things internally, that everything is a class internally, >>> including an interface or a trait. >>> But this is an API for the userland, and in userland this is not true. >>> The 3 structures: classes, interfaces and traits and distinct things that you can use >>> in different ways in (generated) code. >>> >>> I believe that in userland, the common understanding is that enums are just a specific >>> type of class, final ones. >>> I would find it surprising if get_declared_classes() >>> would not return enums. >>> >>> Avoiding a BC break would be nice also if there is no reason for it. >>> One would be able to get only the enums by using something like: >>> ```php >>> function get_declared_enums_only() { >>> return array_diff(get_declared_classes(), get_declared_enums()); >>> } >>> ``` >>> >>> -- >>> Alex >>> >> >> Interesting observation Alexandru, >> >> I find it weird that class_exists("MyEnum") would return true, but there is only >> one symbol table—you can’t name a class and enum with the same name, so it makes some sense. >> However, while enums have “some” similarities with classes in PHP, they are not the same. For >> example, you cannot implement arbitrary interfaces (ie, Stringable), you cannot extend another >> class, you cannot instantiate them with “new”, you cannot have state, you cannot clone them, >> magic methods are forbidden, etc. >> >> You cannot build a “class” with these rules in PHP, so I don’t think enums quack >> sufficiently like classes to be called a class. I would argue that it is an object, however. I think >> it would be worth implementing a get_declared_objects() that behaves like get_declared_classes() >> currently does. >> >> — Rob > > Yes, that's a good point as well. > > I think my view comes from when I initially dug (15+ years ago) into what an enum in Java is, > and learned that it is just a syntactic sugar, and a final class would be generated implementing > Comparable and extending an abstract class > Enum. > > And I think in PHP that could be a similar view. And most of the limitations we have are not > impossible to create with a standard class. > > I think in time we might get to remove some limitations. > I, personally, don't agree with the Stringable related > limitation. > And also with the limitation on no state. In Java this is the simple way to create a singleton: > an enum with one case; and we can't have this in PHP. > > If we remove the limitations, should we reclassify at that point enums as classes? > > -- > Alex > Hey Alex, IMHO, the only thing keeping an enum from being "sugared classes" is the ability to define state. I'm not even sure why it is a limitation because it is relatively easy to "hack it in": https://3v4l.org/nqZfK Being able to define state and behavior are fundamental parts of what makes a class a class. If you can't have state, then I'm not sure it is a class. We're getting into theoretical computer science here, but that is, I think, a generally accepted basic definition in Object Oriented Programming.[1] The rest could be explained as just sugar for: 1. final class 2. extend base enum class (hence why it can't extend another class) 3. final clone method in base class which prevents cloning 4. hidden magic method implementations that throw (hence unable to implement stringable) 5. singletons for each case 6. etc (and before someone argues that it "isn't how it works", I am merely describing the sugar) So, yes, once that restriction is lifted, I think we could officially call them classes. Until then though, I think they're just "enums?" On Wed, Oct 2, 2024, at 14:19, Derick Rethans wrote: > On 2 October 2024 09:06:20 BST, Rob Landers <rob@bottled.codes> wrote: > > >You cannot build a “class” with these rules in PHP, so I don’t think enums quack > >sufficiently like classes to be called a class. I would argue that it is an object, however. I think > >it would be worth implementing a get_declared_objects() that behaves like get_declared_classes() > >currently does. > > Objects are instantiated classes, and not declared elements, so that name wouldn't make > sense. > > cheers > Derick > This is also why I suggested calling them objects instead of classes. Enum cases are instantiated enums which are objects, but they aren't classes. We could be more specific and call it get_declared_object_types() I'd absolutely love to hear a reason, rooted in computer science, why PHP enums are classes. I'm no expert on the subject, but this has bothered me for years... so I would love to learn more or discuss the topic further. [1]: https://books.google.com/books?id=9NGWq3K1RwUC&pg=PA18 Foundations of Object Oriented Languages: types and semantics, Bruce, 2002 -- just had to break out an old text book :) — Rob