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
