[RFC] Abstract final classes

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.collins@gmail.com
wrote:

guilhermeblanco@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]

--

--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

You are correct. Methods cannot be declared abstract if you have an
"abstract final". They must also be static. I added these checks together

To me, it just feels a bit unnatural. So you have abstract class, which
usually has abstract methods. Then you have "abstract final" class which
can not have abstract methods, but instead should have "static" methods.
This just sounds a bit weird to me - adding "final" to description of
the class completely changes all the rules in very unexpected direction.

What does it mean to have an abstract static function? Abstract (non-static) functions make sense for abstract classes -- since you cannot instantiate the abstract class, you know that the instantiable subclass that you actually have an instance of must have implemented the method, so it's safe to call. But you can call static methods on abstract classes, and so you have no guarantee that the abstract static method exists -- and you need to be very careful with LSB to actually call it correctly anyways.

Does this mean that static classes with abstract methods (or abstract static classes, or however this ends up working out syntactically) won't be allowed to have static methods called on them directly? How do you make sure that the methods in them do the right LSB stuff to call the abstract static functions correctly?

Inheritance semantics for static classes also get messy when you start dealing with traits. As a quick example, the current proposal only allows static classes to inherit from other static classes... but where do traits fit in here? Only traits with only static methods are allowed to be included? This could lead to some very annoying refactoring scenarios where changing a trait that is used in several places leads to errors with static classes... traits bring up many of the same issues as multiple inheritance, and I think you'll have some of those issues here.

All of the above is the crux of the issue of why Hack went with "abstract final" and not anything else. Abstract does not mean "must be subclassed" -- you can have an abstract class with no subclasses and still call static methods on it; this is perfectly meaningful, and is at least how I emulated "abstract final" before Hack got the feature. Abstract means "cannot be instantiated" (and, since it cannot be instantiated, may contain instance methods with empty bodies, i.e., abstract methods). Then final means "cannot be subclassed" -- so the two together means you have a class that has no instances itself, and cannot be subclasses, so you can never have an object of that type. The use cases for being able to override such a class are questionable at best, as above.

This really is just the combination of two existing class modifiers -- no need to introduce a new "static" modifier. And it leads to lots of interesting issues, as above.

Josh Watzman