> 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.collins@gmail.com>
wrote:
> guilhermeblanco@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: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
