Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79879
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFp73XvChnyz3LH3=t4zyww+TjpG_XUzq0+1-ygNFP-xApDgfw@mail.gmail.com>
References: <CAFp73XvChnyz3LH3=t4zyww+TjpG_XUzq0+1-ygNFP-xApDgfw@mail.gmail.com>
Date: Tue, 23 Dec 2014 03:34:11 +0000
Message-ID: <CAPwsocEEoK92S-T3_od10k4Z5f+x895YA0JrOzhwZGBubaGPiw@mail.gmail.com>
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Package private class
From: leight@gmail.com (Leigh)

On 23 December 2014 at 00:32, guilhermeblanco@gmail.com
<guilhermeblanco@gmail.com> wrote:
> Hi internals,
>
> I finalized a new proposal for PHP. It consists into adding support for
> package-private classes in the language.
>
> A package private class is basically a class that can only be instantiated
> in its declared namespace. This means that you cannot extend, implement or
> use a class, interface or trait outside of declared namespace. It can be
> referenced outside of the package, but instantiation can only be done there.
>
> Other languages such as Java and C# consider package-private class as a
> top-level class without any declared visibility. PHP cannot enforce this as
> it would be an incredible BC break, but we can reuse an already declared
> keyword "private" to fit this purpose. A class declared without any
> visibility modifier is considered "public" and works exactly as it
> currently does. The same applies to a class written with "public" keyword
> (ie. public class Foo {}).
>
> Most of checks are done at compile time and only instantiation is done at
> runtime (the only place I found out it could be done). Performance impact
> seems negligible as only one top condition is added during instantiation
> bytecode executor.
>
>
> At this stage I want to collect implementation feedback. Explanation is
> done above and the extensive amount of tests self explains what the entire
> purpose of this feature is. RFC will be created together with voting once
> I'm able to gather some considerations.
>
> Link to PR: https://github.com/php/php-src/pull/947
>
>
> Cheers,
>
> --
> Guilherme Blanco
> MSN: guilhermeblanco@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada

Hey Guilherme,

Good work, namespace visibility on classes and functions is something
I have been working on over the past few months. The reason I haven't
created an RFC is because I couldn't decide on what "private" and
"protected" should mean for a class or function within a namespace.

To me, a private class can only be instantiated within it's own
namespace (this seems the same as you have defined), but can be
typehinted and used anywhere else.

Maybe I was wrong to try and include "protected" in my own work, as it
caused me the most problems when trying to define what it should mean.
My original feeling was that it should mean it can only be
instantiated in it's own namespace or sub-namespaces.

I also considered a strict "visibility" view, private classes would
not be "visible" outside of their own namespace, and protected would
not be "visible" outside of their own or child namespaces ("visible"
meaning no type hints or usage too).

It is reassuring to see that your approach is the same as my initial
feelings, the accessibility keywords define instantiation usage,
rather than a strict visibility.

I haven't looked at your patch in detail. My PoC code revolved around
comparing the start of class names with the current namespace. Is
yours the same? How do you feel about extending this to functions?

Thank's for the work on this. I wasn't sure I had the willpower to
finish my patch for PHP7, it's nice to see you have the same idea.

Cheers,

Leigh.