> In the RFC, I think one phrase needs clarification: > > Currently, PHP developers' only resource is to create a final class with > a private constructor, leading to untestable and error prone code. > > What is "error prone" in private __construct(); and how the RFC improves > the testability of such class?
The reason comes not to the construct method itself, but to other implemented methods. By forgetting "static" in any of your declared methods, you get no parse error and gives you 2 possibilities: - With E_STRICT enabled: Fatal error when non-static method is being statically called. You'll only get this at runtime, leading to potentially error prone. Now the testability come that with this addiction, you get a fatal error, which is easily fixable at compile time, not runtime. - With E_STRICT disabled: You get a warning on php log and everything works (which is a huge wtf mode). > The vote should be 2/3+1 surely as it is a language change. Sure, I can update the RFC to clarify this. >> My motivation is to further expand class support to add modifiers (PPP - >> public, protected, private). I added this change to initially segregate >> grammar rules. It was an easy feature without extensive complexity and >> covers some use-cases. > > I'm not sure I understand this part. Could you explain more? My end goal is to add class visibility to PHP. Unfortunately, I was forced to change bison grammar, reduce one ACC flag, so I could add this support. While doing that, I realized that "abstract final" was an easy support to add, since the entire engine already deals with both cases smoothly. All I had to do was remove the compiler check that was fataling and add necessary checks for class members. I stopped to code class visibility so we could vote on small incremental feature addictions. https://github.com/php/php-src/pull/911 is a requirement for class visibility too, because I'll move the ZEND_ACC_TRAIT to a proper binary value and address builtin_functions accordingly. I saw not linear room for a new flag, so I worked on reusing FINAL and now I worked on grammar support as part of this RFC's patch. Next patch will add PPP (public, protected, private) support to classes. > "Abstract final" is a strange way to name it. What you want is a "static" class: > This has always been my feeling. To me, "abstract" means "must be extended", and "final" means "can't be extended", so > combining the two seems like a self-contradiction. > > The fact that abstract classes allow static methods to be called without sub-classing always seems a bit odd to me - it's as > though only the constructor is really abstract, not the whole class. > > A "static" class, however, whether "final" or not, is definitely something I've wanted. > for the record I also brought up this argument (abstract and final being > contradicting ideas) in the pull request comments(before this thread was > created). No, because conceptually, a static something means that subsequent calls always return same value. A static class means a singleton, not what this patch proposal. You have to remember: - "abstract" means it cannot be instantiated directly - "final" means it cannot be extended > The example is a little bit misleading: Instead of a new concept you can use functions, right? Yes, but allowing namespace level functions does not give you property level functions. > Does this mean that the following will be flagged as invalid? If so, what error message will be raised? > > abstract final class Foo { > abstract public function doTheImpossible(); > } > > This class is technically valid as an abstract class, but the addition of the "final" keyword makes the abstract method > declaration completely meaningless, since it can never be implemented. You are correct. Methods cannot be declared abstract if you have an "abstract final". They must also be static. I added these checks together with static properties here: - Properties: https://github.com/php/php-src/pull/923/files#diff-3a8139128d4026ce0cb0c86beba4e6b9R4251 - Methods: https://github.com/php/php-src/pull/923/files#diff-3a8139128d4026ce0cb0c86beba4e6b9R3936 I'm able to expand the RFC in any way you may like before entering voting phase... just mention to me and I do it! =) Cheers, On Thu, Nov 27, 2014 at 8:14 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > guilhermebla...@gmail.com wrote on 27/11/2014 03:47: > >> I worked on an implementation of a somehow controversial concept that >> exists in hack and C#: abstract final classes. >> >> https://wiki.php.net/rfc/abstract_final_class >> > > The explanation of what exactly has been implemented could perhaps be > expanded: > > > Change language scanner to accept abstract final class constructor, and > subsequently restricting to only static members. > > Does this mean that the following will be flagged as invalid? If so, what > error message will be raised? > > abstract final class Foo { > abstract public function doTheImpossible(); > } > > This class is technically valid as an abstract class, but the addition of > the "final" keyword makes the abstract method declaration completely > meaningless, since it can never be implemented. > > > Regards, > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
