Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:79231 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 8716 invoked from network); 27 Nov 2014 14:09:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Nov 2014 14:09:04 -0000 Authentication-Results: pb1.pair.com smtp.mail=guilhermeblanco@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=guilhermeblanco@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.182 as permitted sender) X-PHP-List-Original-Sender: guilhermeblanco@gmail.com X-Host-Fingerprint: 209.85.223.182 mail-ie0-f182.google.com Received: from [209.85.223.182] ([209.85.223.182:34193] helo=mail-ie0-f182.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C2/D2-27910-B7037745 for ; Thu, 27 Nov 2014 09:09:00 -0500 Received: by mail-ie0-f182.google.com with SMTP id x19so4573482ier.27 for ; Thu, 27 Nov 2014 06:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UB51+UuUPMYkQqbqHviKGZt+jDmA9zKE37V2QVSbueQ=; b=LkR6o+RuZFBG3skEZbmWc0EiMSXPz5HrMNvw4/H86K8d5HsDFyzpmqrZ7TWEhzcvzH LecD3vxQV145BZ+Jrsn7MZW8o8OLXzunRTKVsGNGq0tpZhBWRRxNEpe6Y923KwHamSNT l5h8ebft1OPS0xZtSMM4P812bzaFBj9mq0TRUkv3O8osFH7duv5cl1zwQSfIfkR8Qx9E sO9aMDvI0tgmZ21Y3vQLjCVHavAyTaH7T1Yx00lajKGZ8EB29PF/8OGT1/K2IvrFRaCj QTdVzJs5oRAAzS6qGaG0IWj9bFk5yySdyqBuWTWsNUhaVemvSSsb2dZXzyfqjFuQp1Z/ KhZA== X-Received: by 10.50.25.100 with SMTP id b4mr28202734igg.17.1417097336625; Thu, 27 Nov 2014 06:08:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.238.75 with HTTP; Thu, 27 Nov 2014 06:08:36 -0800 (PST) In-Reply-To: <547723A8.8090008@gmail.com> References: <547723A8.8090008@gmail.com> Date: Thu, 27 Nov 2014 09:08:36 -0500 Message-ID: To: Rowan Collins Cc: PHP internals Content-Type: multipart/alternative; boundary=047d7bd74a345ca1d80508d7af0e Subject: Re: [PHP-DEV] [RFC] Abstract final classes From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com") --047d7bd74a345ca1d80508d7af0e Content-Type: text/plain; charset=UTF-8 > 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 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 --047d7bd74a345ca1d80508d7af0e--