Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79213
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.54 as permitted sender)
Message-ID: <5476D068.8080101@gmail.com>
Date: Wed, 26 Nov 2014 23:19:04 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAFp73XvRNoDF5N1-H4+YBSB3G2_OBAM3+x6Tu3beT5-H9O+deg@mail.gmail.com>
In-Reply-To: <CAFp73XvRNoDF5N1-H4+YBSB3G2_OBAM3+x6Tu3beT5-H9O+deg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Abstract final classes
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> 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

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 vote should be 2/3+1 surely as it is a language change.

> 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?
-- 
Stas Malyshev
smalyshev@gmail.com