Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79389
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain fb.com does not designate 67.231.153.30 as permitted sender)
To: Stanislav Malyshev <smalyshev@gmail.com>
CC: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>,
        Rowan Collins
	<rowan.collins@gmail.com>,
        PHP internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Abstract final classes
Thread-Index: AQHQCfUHwSNZMDBLqUOftPvN8Cufipx0+kkAgAAPLgCAARN2gIAHRRWA
Date: Tue, 2 Dec 2014 21:35:34 +0000
Message-ID: <9C4E199C-2129-45B4-91E8-5D7652E1AE9A@fb.com>
References: <CAFp73XvRNoDF5N1-H4+YBSB3G2_OBAM3+x6Tu3beT5-H9O+deg@mail.gmail.com>
 <547723A8.8090008@gmail.com>
 <CAFp73Xvh1UrMpH9Kp9AVEinqEX72Qo2Su+TPgc-VVcRrPh4q1w@mail.gmail.com>
 <54781777.6090208@gmail.com>
In-Reply-To: <54781777.6090208@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <98BE691B87704D45B90DC8E526B1FE85@fb.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Abstract final classes
From: jwatzman@fb.com (Josh Watzman)

On Nov 27, 2014, at 10:34 PM, Stanislav Malyshev <smalyshev@gmail.com> wrot=
e:

>> You are correct. Methods cannot be declared abstract if you have an
>> "abstract final". They must also be static. I added these checks togethe=
r
>=20
> To me, it just feels a bit unnatural. So you have abstract class, which
> usually has abstract methods. Then you have "abstract final" class which
> can not have abstract methods, but instead should have "static" methods.
> This just sounds a bit weird to me - adding "final" to description of
> the class completely changes all the rules in very unexpected direction.

What does it mean to have an abstract static function? Abstract (non-static=
) functions make sense for abstract classes -- since you cannot instantiate=
 the abstract class, you know that the instantiable subclass that you actua=
lly have an instance of must have implemented the method, so it's safe to c=
all. But you *can* call static methods on abstract classes, and so you have=
 no guarantee that the abstract static method exists -- and you need to be =
very careful with LSB to actually call it correctly anyways.

Does this mean that static classes with abstract methods (or abstract stati=
c classes, or however this ends up working out syntactically) won't be allo=
wed to have static methods called on them directly? How do you make sure th=
at the methods in them do the right LSB stuff to call the abstract static f=
unctions correctly?

Inheritance semantics for static classes also get messy when you start deal=
ing with traits. As a quick example, the current proposal only allows stati=
c classes to inherit from other static classes... but where do traits fit i=
n here? Only traits with only static methods are allowed to be included? Th=
is could lead to some very annoying refactoring scenarios where changing a =
trait that is used in several places leads to errors with static classes...=
 traits bring up many of the same issues as multiple inheritance, and I thi=
nk you'll have some of those issues here.

All of the above is the crux of the issue of why Hack went with "abstract f=
inal" and not anything else. Abstract does not mean "must be subclassed" --=
 you can have an abstract class with no subclasses and still call static me=
thods on it; this is perfectly meaningful, and is at least how I emulated "=
abstract final" before Hack got the feature. Abstract means "cannot be inst=
antiated" (and, since it cannot be instantiated, may contain *instance* met=
hods with empty bodies, i.e., abstract methods). Then final means "cannot b=
e subclassed" -- so the two together means you have a class that has no ins=
tances itself, and cannot be subclasses, so you can never have an object of=
 that type. The use cases for being able to override such a class are quest=
ionable at best, as above.

This really is just the combination of two existing class modifiers -- no n=
eed to introduce a new "static" modifier. And it leads to lots of interesti=
ng issues, as above.

Josh Watzman