Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92141
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5706A182.6080401@gmail.com>
References: <56ED495C.80809@fleshgrinder.com> <57069A72.7030100@fleshgrinder.com>
 <5706A182.6080401@gmail.com>
Date: Thu, 7 Apr 2016 14:32:30 -0400
Message-ID: <CAFp73XssJqErBRzi=Y4W4oppfw57pAwqYz-QZF11xsjjZygn9g@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11335e143cf066052fe94ef3
Subject: Re: [PHP-DEV] Access and Visibility Modifiers
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--001a11335e143cf066052fe94ef3
Content-Type: text/plain; charset=UTF-8

Hi,

I was working on a private-class support for PHP an year ago, until I hit a
problem I couldn't fix myself.
Now I have some more expertise of what I could do to resolve it, but I
still didn't start on rebase/update of patch yet.
However, I'd like to describe my line of thinking here, so people can
debate about it even without me working on an updated patch yet. It's a
preliminary work that needs to happen before people spend time on a patch,
that will later be transformed into an RFC.

The situation that brought me to work on this is, as a library developer,
people reuse internal classes that are not meant to be reused outside of
library's code. Changes to its API can potentially break consumers of the
library, making upgrades hard to happen.
To mitigate this problem, I thought about working on two patches to the
language that could help library/application developers, self-containing
code that is not meant to be reused. They're detailed as follow:

1- Private-class visibility: Only classes in the same namespace (siblings)
or child ones could instantiate the class. Cloning would still be possible
outside of namespace's scope, the same to access public members.
This is what is currently 90% done in:
https://github.com/php/php-src/pull/947
It requires changes to Zend Engine to include a start namespace and an end
namespace opcodes, allowing to locate in which scope you are. There are
failing tests that are not passing because of this right now.

2- Protected-class visibility: It would work the same way as private-class
visibility, but with the difference that other classes in the same
namespace/child namespaces could access protected members of the specified
protected class.

Of course both of them would require to go through RFC writing, idea
validation, voting and performance assessment process, but it's already a
start.


Regards,

On Thu, Apr 7, 2016 at 2:05 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> Fleshgrinder wrote on 07/04/2016 18:35:
>
>> 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
>>
>
> I'm not convinced of the value of reusing the keyword in this way. To me,
> there is nothing in the term "var" that means "slightly less than public",
> and if we want to have package/assembly/whatever visibility, we should
> reserve a new keyword for that use.
>
> Meanwhile, it might be worth checking the list archives for previous
> discussions of package visibility; I know it has come up a couple of times
> recently, in various forms, so it would be good not to repeat the same
> points again and again.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>



-- 
Guilherme Blanco
Lead Architect at E-Block

--001a11335e143cf066052fe94ef3--