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. :)
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
