On 3/19/2016 12:51 PM, Fleshgrinder wrote:
> I just thought about this some more and this is actually not true.
>
> namespace Fleshgrinder\Examples\PhpInternals;
>
> final class A {
> int $x;
> var $y;
> $z;
>
> function getX() {
> return $this->x;
> }
> }
>
> Everything is public here, as we already agreed upon and changing that
> would be a topic for 8.0 or 9.0. The *var* keyword should be banned imho
> but I do not know about the *$z* in the example. Is this even possible
> with the parser? Otherwise we could keep the *var* keyword because with
> my proposal here it would become useful again.
>
> assembly fleshgrinder/experiments;
>
> namespace Fleshgrinder\Examples\PhpInternals;
>
> final class A {
> int $x;
>
> function getX() {
> return $this->x;
> }
> }
>
> Where *assembly* could also be *module*, *package*, ... and it allows
> one to group multiple classes and namespaces together across composer
> packages. Furthermore it alters the access and visibility of members. In
> the above example where no visibility modifiers are specified both the
> class /A/ and the method /getX/ are only accessible within the
> *fleshgrinder/experiments* assembly. This approach would allow the
> introduction of such a system in a feature release (7.x.0) without
> breaking changes. Either the new keyword is present and missing
> visibility modifiers are globally scoped (hence implicit public) due to
> everything being in the global assembly by default or the new keyword is
> present and missing visibility modifiers are restricting access to the
> assembly.
>
> Usage of the word /package/ could be a blessing and a curse at the same
> time because the word is already heavily in use in the PHP world, e.g.
> /@package/ in DocBlocks or in /composer package/.
>
> The same holds true for /module/ because it is sometimes used to refer
> to PHP extensions and PEAR uses it.
>
> Hence, *assembly* might be the best choice here and is my proposal.
>
> The following proposal in regards to access and visibility is not well
> thought through but hopefully a starting point:
>
> # Methods
> private := limited to the current class
> protected := limited to the current and child classes
> := limited to the current assembly
> public := global
>
> # Properties
> private := limited to the current class
> protected := limited to the current and child classes
> := limited to the current assembly
> public := global
> var := E_STRICT or limited to the current assembly
>
> # Classes, Interfaces, and Traits
> private := limited to the current namespace
> protected := limited to the current and child namespaces
> := limited to the current assembly
> public := global
>
> Default assembly is always global and old code would not change at all. :)
>
I would like to change above definition for properties since the *var*
deprecation was voted negative:
# Properties
private := limited to the current class
protected := limited to the current and child classes
var := limited to the current assembly
public := global
And here is a list of additional keywords I collected that could be used
instead of *assembly* (which I do not like that much):
- group
- crate (used by Rust)
- unit
- segment
- kit
- container
- bin
- ...
I was also thinking about prescribing some parsable format for the
content of this new keyword. I do not see a real value in doing so since
such an identifier does not bare any meaning other than grouping
namespaces and classes together, hence, we could simply use a string, e.g.:
assembly 'WhatEver!';
On the other side, not specifying anything parsable might result in
misuse in the community. An alternative would be to reuse the namespace
syntax. The advantage would be that users do not have to learn a new
syntax. A disadvantage is that is looks very similar to namespaces. A
third option is to use the composer package naming conventions. Yes we
would be pulling in something from a userland tool here but we would
actually just say that composer did something good here and bless it.
The syntax would be:
assembly <vendor>/<name>;
/[a-z](?:[_-]?[a-z0-9])*\/[a-z](?:[_-]?[a-z0-9])*/Di
This syntax would be extremely strict compared to the possibilities for
other identifiers in PHP and the PCRE might need to be extended if this
is an option you find worth pursuing.
Would love to here some general feedback on the idea.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
