Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79338
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender)
To: "'internals'" <internals@lists.php.net>
Cc: <guilhermeblanco@gmail.com>
Date: Mon, 1 Dec 2014 14:58:58 +0100
Message-ID: <003c01d00d6e$f4fd77c0$def86740$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AdANbSi4xcqlp7PXRt228GnJQfJ+cg==
Content-Language: de-ch
Subject: [RFC] Static classes (Was Abstract final classes)
From: php@tutteli.ch ("Robert Stoll")

Hi Guilherme,

I read your updated RFC:
https://wiki.php.net/rfc/abstract_final_class

IMO the RFC as such makes sense now (abstract final confusion is =
eliminated. In addition to turn methods implicitly into static methods, =
the __construct of a static class should be implicitly private as well.
I am not sure what makes more sense for PHP, but just as =
thought-provoking impulse, wouldn't it be better just to check that all =
methods are static and __construct private instead of turning methods =
magically into static methods and __construct private?

And then there is one bit which I do not understand. What do you mean =
with:
"There's no way of adding static variables to a namespace. This would =
address this issue too."

How does this RFC address this problem?=20

Cheers,
Robert