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
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.
I was thinking the very same thing after __construct() came up, but wasn’t sure how it should work. :)
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?
I think it’s a good idea, the problem is defining private and protected.
I wonder if this is something autoloaders could handle? private classes might be visible only within the same file, while protected classes might be visible only to other files the autoloader can see.
--
Andrea Faulds
http://ajf.me/
I think parts of this can easily be handled in zend_compile.
Other pieces requires runtime introspection that could be done at
zend_vm_def. My only concern is how to know what's the active scope
(class)...
While researching for data flow, I also saw that with the inclusion of AST,
some checks currently in zend_inheritance could be moved to zend_compile
too.
If we can discuss and reach some consensus, I can work (or at least try to)
on a patch and propose officially as an RFC. But before doing that, we need
to resolve how private/protected should behave. My suggestion could work,
but it may not be a sane approach.
[]s,
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.I was thinking the very same thing after __construct() came up, but wasn’t
sure how it should work. :)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?
I think it’s a good idea, the problem is defining private and protected.
I wonder if this is something autoloaders could handle? private classes
might be visible only within the same file, while protected classes might
be visible only to other files the autoloader can see.--
Andrea Faulds
http://ajf.me/
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada