Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78947
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.169 as permitted sender)
MIME-Version: 1.0
Date: Tue, 18 Nov 2014 12:33:15 -0500
Message-ID: <CAFp73Xu9yq6qLaYUO57CHj4=1g=naxQceNV4fNMca73e6WjpJw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0141a8dcb3b97f0508257e28
Subject: [IDEA] Class modifiers support expansion
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--089e0141a8dcb3b97f0508257e28
Content-Type: text/plain; charset=UTF-8

Hi internals,

Library developers sometimes plan for extensibility of their code, but not
all pieces are able to be extended and unexpected usage can lead to
unpredictable behavior.
Based on that, I consider it may be a good addition to PHP to add class
visibility support and enhance existing modifiers' support.

First, we should discuss about possible enhancements on current existing
class modifiers' support (abstract and final). Currently, just as an
example, I can create a trait with abstract methods, but I cannot declare
an abstract trait.
My proposed enhancements are:

- abstract traits: Currently we only add implicit abstract. We should allow
explicit declarations too. Nothing to change in the overall support, seems
just a scanner inclusion.
- final traits: prevent to be composed in other traits
- final interfaces: prevent to be extended in other interfaces

By adding these minor additions, we may likely simplify the scanner a bit.
This would also make easier to support class visibility in the scanner.

Unfortunately, PHP does not support nested classes. Personally speaking, I
feel that the language can live happy without it, as soon as we can have
class visibility support.

Now what I mean by class visibility, it requires a better discussion on how
it could behave, since any other language relies on nested classes to
expose this support. Nevertheless, PHP's lack of Open/Close principle
support could be addressed easily. This is my POV on how it could behave:

- private classes: Can only be extended and instantiated inside of the same
namespace it sits. This is the similar to private-package support in Java.
- protected classes: I can't determine any similarity to any other language
in this one, but it could behave somehow like: can be extended and
instantiated anywhere within the root namespace.
- public classes: same as current PHP support

What do you think about it?

Cheers,

-- 
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--089e0141a8dcb3b97f0508257e28--