> -----Ursprüngliche Nachricht-----
> Von: Leigh [mailto:lei...@gmail.com]
> Gesendet: Dienstag, 23. Dezember 2014 04:34
> An: guilhermebla...@gmail.com
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] [RFC] Package private class
>
> On 23 December 2014 at 00:32, guilhermebla...@gmail.com
> <guilhermebla...@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: guilhermebla...@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.
>
> --
> 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 the same assembly (correct me if I
am wrong).
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).
Yet, I would prefer something like C#'s internal - defining that a certain
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 above example the
class Foo would also be visible within the namespace ch.tutteli and within the
namespace ch.tsphp as well as its sub-namespaces (denoted by the * at the end)
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.
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
