My thoughts are that no additional keyword is necessary - allow protected
and private to be used in this scopes. A protected element of a namespace
can be accessed within that namespace or any sub-namespaces, and a private
element would only be visible by code in the same namespace. Hence
namespace A {
protected class Bar(){}
}
namespace B {
new \A\Bar(); // fails, protected.
}
namespace A\C {
new \A\Bar(); // works, C is A's child.
private class Foo();
}
namespace A\C\D {
new \A\C\Foo(); // fails, private and only reachable from \A\C
}
This accomplishes the same as the proposed keyword, and then some, and
doesn't introduce the BC break of a new keyword.
On Fri, Mar 1, 2013 at 6:11 AM, Julien Pauli <jpa...@php.net> wrote:
> On Thu, Feb 28, 2013 at 12:40 PM, Lazare Inepologlou <linep...@gmail.com
> >wrote:
>
> > Hello,
> >
> > please read my comment inline...
> >
> > 2013/2/28 Sebastian Krebs <krebs....@gmail.com>
> >
> > > 2013/2/28 Jens Riisom Schultz <ibmu...@me.com>
> > >
> > > > Hi everyone,
> > > >
> > > > (I got "hooked off" this discussion, so I have tried to keep up by
> > > reading
> > > > the digest... This makes it impossible for me to correctly interleave
> > my
> > > > comments, so I'll just "top post" or whatever the term is) (I'm sure
> > this
> > > > has been mentioned before but a forum would be so much more accesible
> > > than
> > > > this mailing list concept...)
> > > >
> > > >
> > > > * In response to the argument that you want to be able to modify a
> > > > framework or use it in an unintended manner:
> > > > This would be possible by explicitly stating "namespace Framework;"
> in
> > a
> > > > given php file.
> > > >
> > > > * In response to the argument that php has no assembly concept:
> > > > I know this, but namespaces are as close as we get, and would
> > effectively
> > > > solve this.
> > > >
> > >
> > > No. A namespace is in fact more or less just a prefix, that groups the
> > > containing elements together. Beside the semantic meaning of grouping
> > they
> > > don't have any further abilities, or meaning.
> > > Without knowing exact details I guess, that "internal" in C# is
> primary a
> > > technical thing, that allows a compiler further optimizations, because
> he
> > > definitely knows, that the function/method is only used within the
> > assembly
> > > and is not required to do anything to expose it to the outside?
> > >
> > >
> > Regardless of the technical details, it is still a fine way of applying
> > encaptulation so you can't say that it is only a technical thing.
> >
> >
> > >
> > > >
> > > > * In response to the argument that php already has accessibility
> > > > restrictions with private and protected:
> > > > This is true, but it does not solve all problems. Often you need
> > classes
> > > > to interoperate in a way that can only be facilitated by making
> > > > functionality public. Also, there is no way to make a private or
> > > protected
> > > > class (since php has no assembly concept), though what I propose
> would
> > > > likely birth the concept of private and protected classes as well.
> > > >
> > >
> > > Maybe it's just me, but no: I've never had the need of what you
> describe
> > > and where a public method wasn't apropriate anway... At least for a
> very
> > > long time :D
> > >
> > >
> > > >
> > > > * In response to the argument that PHP does not restrict anyone from
> > > > adding to a namespace:
> > > > That is true, but say you were using Doctrine2. Would you ever make a
> > php
> > > > file with "namespace Doctrine2;" in it, unless you wanted to modify
> > > > Doctrine2, and hence you knew what you were doing, or accepted the
> > risks?
> > > >
> > >
> > > Well, yes. But extending/overriding a components method _always_
> > requires,
> > > that you know what you do, so why enforcing/encouraging hacks, instead
> of
> > > the good old "protected"?
> > >
> > >
> > "Protected" is used for extending classes. There is no mechanism to
> inherit
> > and extend a namespace so "protected" is irrelevant here.
> >
> >
> > >
> > > >
> > > > * In response to the concept of solving this through documentation:
> > > > First off, this is not possible with the current phpdoc and phpdoc2
> > > > standards. Second off, problems like these should not be solved by
> > > > documentation, imho, or of course I would not propose this. The C#
> > > > designers seem to agree with me. And the Java designers, too (though
> > they
> > > > have no internal keyword they do have a way of hiding framework
> > specific
> > > > classes).
> > > >
> > >
> >
> >
> > Actually Java has a concept that is identical to your proposal. The
> default
> > access modifier (when no access modifier is written) is the "package"
> > modifier (=accessible from within the same package).
> >
> > Ha, it's been years since I'm asking for such a feature to come to PHP.
>
> I would love to see a package visibility in PHP, restricting access to
> 'package'ed members (methods or attributes) to an object born from a class
> of the same namespace.
> Would really help some cases in frameworks or so :-)
>
> Just my2cents
>
> Julien
>
