Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79886
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: <001e01d01e97$143188f0$3c949ad0$@tutteli.ch>
References: <CAFp73XvChnyz3LH3=t4zyww+TjpG_XUzq0+1-ygNFP-xApDgfw@mail.gmail.com>
 <CAPwsocEEoK92S-T3_od10k4Z5f+x895YA0JrOzhwZGBubaGPiw@mail.gmail.com> <001e01d01e97$143188f0$3c949ad0$@tutteli.ch>
Date: Tue, 23 Dec 2014 12:52:00 -0200
Message-ID: <CAFp73Xs3XQCOXQfwaUkdFkB5-MfNfxgXKsV73=2-W6GJDW-z5w@mail.gmail.com>
To: Robert Stoll <php@tutteli.ch>
Cc: Leigh <leight@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01183eda71b8e3050ae3522d
Subject: Re: [PHP-DEV] [RFC] Package private class
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--089e01183eda71b8e3050ae3522d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Robert,

Answers inline.

On Tue, Dec 23, 2014 at 7:59 AM, Robert Stoll <php@tutteli.ch> wrote:

>
>
> > -----Urspr=C3=BCngliche Nachricht-----
> > Von: Leigh [mailto:leight@gmail.com]
> > Gesendet: Dienstag, 23. Dezember 2014 04:34
> > An: guilhermeblanco@gmail.com
> > Cc: PHP internals
> > Betreff: Re: [PHP-DEV] [RFC] Package private class
> >
> > 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 don=
e
> > > 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 th=
e
> > > 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 wha=
t
> "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.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> visit: http://www.php.net/unsub.php
>
> [Robert Stoll]
>
> Hey Guilherme,
>
> I like the idea but I am not sure whether it is wise to define private in
> the way you did, namely that such classes can be seen outside of its
> namespace. You referenced Java, which behaves differently for instance.
> Classes not defined public are only visible in the same namespace. C#
> classes with "internal" are visible in other namespaces but only within t=
he
> same assembly (correct me if I am wrong).
>

I understand how C# and Java define class visibility and even inside of PR
I mentioned that (
https://github.com/php/php-src/pull/947#discussion_r21542750 ).

I would think of private classes in PHP as Java has implemented them hence
> they are not visible outside of its namespace. Why? I think one specifies
> private classes if he/she wants to hide the concrete implementation to
> others and hence it does not make sense IMO that it can be used as type
> hint outside. One should use the corresponding interface instead.
> Therefore, I believe it promotes better code style if we do not restrict
> the visibility to instantiation only. I think a private class should not =
be
> visible at all to others (cannot be used as type hint either).
>

Please remember that Java supports 4 levels of visibility on nested classes
and only 2 on top level classes.
What I added support is basically the 2 top level class visibility
supported, since PHP does not allow nested classes.
For top level classes, the allowed visibilities are public and
package-private. Public classes can be instantiated anywhere in the code. I
was forced to make this default in PHP to keep BC, which brought me the
decision on how to classify package-private. I used private because there's
no other semantical meaning when talking about top-level classes.


>
> Yet, I would prefer something like C#'s internal - defining that a certai=
n
> class is only visible within my own project (can still not be seen by
> others), but that does not seem feasible right now since PHP has not an
> assembly like structure. But, just as an idea which just popped into my
> head, maybe we could introduce something as follows as well (clearly
> another RFC - but might affect how we define private classes):
>
> namespace ch.tutteli.foo{
>    public for ch.tutteli.bar, ch.tsphp*
>    private class Foo{}
> }
>
> Syntax should not matter, can be changed respectively. The idea would be,
> that we can define a class private (only visible within its own namespace=
)
> but can give access to it by specifying "public for" clauses - in the abo=
ve
> example the class Foo would also be visible within the namespace ch.tutte=
li
> and within the namespace ch.tsphp as well as its sub-namespaces (denoted =
by
> the * at the end)
>

That would add a lot of overhead IMHO to library developers, since now
you'd be required to specify who and where classes are allowed. That would
demand tons of runtime checks, which is definitely a no-go since it may
hurt performance a lot.

Maybe it would make sense to introduce a protected modifier as well which
> means, it is visible along the namespace tree - visible within the same
> namespace as well as its sub-namespaces and parent namespaces (this would
> fit with protected as access modifier of members).
> However, this would be another RFC of course but we should consider such
> ideas before deciding what private classes mean in PHP.
>

I thought a lot about protected class support too. But when drafting my
original proposal, I started to ask myself how feasible it would be to
support only declared and sub-namespaces. In reality, dependencies between
sibling namespaces under same vendor name is not a breakage in modeling, so
protected made zero sense to me.
I decided to research around other language implementations but saw nothing
that applied to top level classes.

You can come up with a plan outside of my proposal (or as an enhancement of
my proposal if accepted), but I would keep implementation as is for now
until acceptance phase if none finds a problem on how I tackled this
support.


>
> Cheers,
> Robert
>
>


--=20
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--089e01183eda71b8e3050ae3522d--