On 3/19/2016 12:51 PM, Fleshgrinder wrote:
> Moving this to a new thread in order to not spam the other.
>
> On 3/19/2016 11:48 AM, Fleshgrinder wrote:
>> On 3/19/2016 11:38 AM, Björn Larsson wrote:
>>> Den 2016-03-18 kl. 21:12, skrev Fleshgrinder:
>>>> No worries you are not, not at all. I just wanted to thwart you and
>>>> others in directly assigning ...
>>>>
>>>> final class A {
>>>> int $x;
>>>> }
>>>>
>>>> ... to be *public* and obstruct the opportunity of assigning it a
>>>> meaningful new functionality.
>>>>
>>> Well, but if one should assign int $x without visibility keyword a
>>> meaning, shouldn't it be the same as for function y() {} without
>>> keyword, i.e. public?
>>>
>>> Of course one can change both, but that sounds like a 8.0 topic.
>>>
>>> Regards //Björn
>>>
>>>
>>
>> It is a sad state the implicit public properties use *var* and implicit
>> public methods nothing, this makes the introduction of new visibility
>> modifiers terribly complicated. You are completely right, they should be
>> the same and *var* should be banned. It is consistent and that is very
>> important. I cannot and do not want to argue against this. Yet at the
>> same time the lack of access (and additional visibility) modifiers is
>> what I am missing the most. Seems as if this has to wait for 8.0 (or
>> 9.0, depending on the resistance). :(
>>
>
> 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. :)
>Reposting to make sure that this is a new thread. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
