> This is true of classes intended to be static whether or not they are final. Allowing a "static class" would allow you to > enforce that all methods (and properties) must be static without banning users from extending it (which is a completely > orthogonal decision).
So if I still want to not allow anyone to extend it, I would then have a final static class. Remember, I don't want people to change methods' visibility. How does that become different from final abstract? I know you answered below... =) > That's not how they're interpreted with regard to methods, unless I'm missing something: > > - "abstract function" means a method which must be implemented by a sub-class > - "static function" means a method with no access to $this, operating outside of any instance > > Taking those behaviours for class definitions leads to the interpretation that seems natural to me: > > - "abstract class" means a class which must be extended before use, and may contain abstract methods > - "static class" would mean a class which can never be used to create an instance, and can contain only static methods > > "final" is orthogonal to these, and means that a class cannot be extended; under this interpretation, "abstract final" is a > contradiction, but "static final" makes perfect sense. The piece it's missing in "static" definition: there can only be one instance of something. I'd argue that declaring a class static is the same as declaring a singleton. Multiple object instantiations over a static class would return always same instance. Now taking this into consideration, I'd modify your concepts to the following: - "abstract function" means a method which must be implemented by a sub-class - "static function" means a method with no access to $this, operating outside of any instance. This means it's bound to class entry, which can only have one possibility to be called: statically and given same parameters it should return same output, unless normal flow controlled by a static variable. I'm more than happy to change "abstract" to "static" if it's the desire of everybody. That would match C# implementation as defined here: http://msdn.microsoft.com/en-us/library/79b3xss3.aspx Now it's funny that C# also accepts "abstract final" with the same idea/concept of their documentation of static classes. #weird []s, On Thu, Nov 27, 2014 at 10:06 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > guilhermebla...@gmail.com wrote on 27/11/2014 14:08: > >> > 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). >> > > This is true of classes intended to be static whether or not they are > final. Allowing a "static class" would allow you to enforce that all > methods (and properties) must be static without banning users from > extending it (which is a completely orthogonal decision). > > > > "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 >> > > That's not how they're interpreted with regard to methods, unless I'm > missing something: > > - "abstract function" means a method which must be implemented by a > sub-class > - "static function" means a method with no access to $this, operating > outside of any instance > > Taking those behaviours for class definitions leads to the interpretation > that seems natural to me: > > - "abstract class" means a class which must be extended before use, and > may contain abstract methods > - "static class" would mean a class which can never be used to create an > instance, and can contain only static methods > > "final" is orthogonal to these, and means that a class cannot be extended; > under this interpretation, "abstract final" is a contradiction, but "static > final" makes perfect sense. > > > 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
