Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79232
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.172 as permitted sender)
Message-ID: <54773DD8.7030907@gmail.com>
Date: Thu, 27 Nov 2014 15:06:00 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <CAFp73XvRNoDF5N1-H4+YBSB3G2_OBAM3+x6Tu3beT5-H9O+deg@mail.gmail.com> <547723A8.8090008@gmail.com> <CAFp73Xvh1UrMpH9Kp9AVEinqEX72Qo2Su+TPgc-VVcRrPh4q1w@mail.gmail.com>
In-Reply-To: <CAFp73Xvh1UrMpH9Kp9AVEinqEX72Qo2Su+TPgc-VVcRrPh4q1w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Abstract final classes
From: rowan.collins@gmail.com (Rowan Collins)

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]