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
namespa
On Thu, Feb 28, 2013 at 12:40 PM, Lazare Inepologlou wrote:
> Hello,
>
> please read my comment inline...
>
> 2013/2/28 Sebastian Krebs
>
> > 2013/2/28 Jens Riisom Schultz
> >
> > > Hi everyone,
> > >
> > > (I got "hooked off" this discussion, so I have tried to keep up by
> > reading
> > > the
> Setting aside difficulty of implementation, I'm coming around to the idea,
> though I think you could simplify it by cordoning off an entire namespace.
> E.g.:
>
> A namespace at least two deep (e.g. \A\B\) may be marked 'protected' (by some
> method TBD). Classes and functions declared in a
On Feb 28, 2013, at 5:59 PM, Fabian Becker wrote:
> Hi Jens,
> I see two problems with your proposal:
>
> > "For example the following class, "namespace Framework; internal class
> > Something {}", would only be visible from within the "Framework" namespace."
>
> What about classes in a sub-n
Setting aside difficulty of implementation, I'm coming around to the idea, though I think
you could simplify it by cordoning off an entire namespace. E.g.:
A namespace at least two deep (e.g. \A\B\) may be marked 'protected' (by some method TBD).
Classes and functions declared in a protected na
Hi Jens,
I see two problems with your proposal:
> "For example the following class, "namespace Framework; internal
class Something {}", would only be visible from within the "Framework"
namespace."
What about classes in a sub-namespace of Framework? Will classes in
\Framework\Foo have access
Hello,
please read my comment inline...
2013/2/28 Sebastian Krebs
> 2013/2/28 Jens Riisom Schultz
>
> > 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, s
2013/2/28 Jens Riisom Schultz
> 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 b
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
On 2/27/13 10:22 AM, Sebastian Krebs wrote:
2013/2/27 Steve Clay
phpDoc already supports "@access private" for items to be left out of
public documentation. An IDE could be configured to have these items appear
greyed or not to appear in autocomplete lists.
a) You misuse the "private visibil
2013/2/27 Steve Clay
> On 2/27/13 3:18 AM, Nikita Nefedov wrote:
>
>> I, for one, think it should be solved on the IDE side. I used a lot of
>> Doctrine's internal
>> methods lately and if they would be not accessible I wouldn't be able to
>> do a lot of things.
>> Of course internal methods/clas
On 2/27/13 3:18 AM, Nikita Nefedov wrote:
I, for one, think it should be solved on the IDE side. I used a lot of
Doctrine's internal
methods lately and if they would be not accessible I wouldn't be able to do a
lot of things.
Of course internal methods/classes shouldn't be exposed as a part of
Hello,
2013/2/27 Jens Riisom Schultz
> Hi,
>
> I just want to get a feel for whether the following idea would be
> instantly rejected (for example I get the feeling that adding keywords is a
> big deal):
>
> Often, when writing frameworks, you need to make public or protected
> functionality or
2013/2/27 Jens Riisom Schultz
> Hi,
>
> I just want to get a feel for whether the following idea would be
> instantly rejected (for example I get the feeling that adding keywords is a
> big deal):
>
> Often, when writing frameworks, you need to make public or protected
> functionality or classes
On Wed, 27 Feb 2013 11:07:06 +0400, Jens Riisom Schultz
wrote:
Hi,
I just want to get a feel for whether the following idea would be
instantly rejected (for example I get the feeling that adding keywords
is a big deal):
Often, when writing frameworks, you need to make public or protect
Hi,
I just want to get a feel for whether the following idea would be instantly
rejected (for example I get the feeling that adding keywords is a big deal):
Often, when writing frameworks, you need to make public or protected
functionality or classes which should only be called from inside the
16 matches
Mail list logo
