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?
>
> * 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"?
>
> * 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).
>
> Information hiding is one of the staples of good OOP, and the internal
> keyword would facilitate further information hiding in a way which is
> extremely hard to do as php is now.
>
> I would like to finish off with an example - I can tell there is a huge
> resistance to this but I do not agree with your arguments, so I'll give it
> another shot.
>
> <?php
>
> namespace Framework;
>
> class PublicAPIClass {
> public function doStuff() {
> $instance = new InternalClass();
> return $instance->doInternalStuff();
> }
>
> internal public static function internalStuffHelper() {}
> }
>
> internal class InternalClass {
> public function doInternalStuff() {
> return PublicAPIClass::internalStuffHelper();
> }
> }
>
This doesn't explain, why the "InternalClass" should be hidden? Additional
the "new" in "doStuff()" and the cyclic calls let me believe, that you'll
have a "tight coupling"-problem anyway.
abstract class APIAbstract {
protected function doInternalStuff() {
return PublicAPIClass::internalStuffHelper();
}
protected static function internalStuffHelper();
}
>
> namespace NotTheFramework;
>
> $instance = new \Framework\PublicAPIClass();
> $instance->doStuff();
>
> // You would not be able to do the following things:
> use Framework\InternalClass;
>
> $instance = new \Framework\InternalClass();
>
> \FrameWork\PublicAPIClass::internalStuffHelper();
>
And the question remains: Why _should_ I not be able to do this? If it is
that specific to the "PublicAPIClass" maybe it should be an abstract parent
instead? Or a trait?
If it is _not_ that specific to "PublicAPIClass" ... well, ehm, this can't
be, because it calls "internalStuffHelper()", thus it is bound to the class
in any case. :)
>
> ?>
>
> Please read my example carefully, before simply writing it off.
>
> ...And a question: Am I wrong when I assume that this should be
> "relatively" easy to implement?
>
> -Jens Riisom Schultz
>
>
> On Feb 27, 2013, at 10:11 AM, Lazare Inepologlou <linep...@gmail.com>
> wrote:
>
> > Hello,
> >
> > 2013/2/27 Jens Riisom Schultz <ibmu...@me.com>
> > 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
> framework. You CAN ensure this with a lot of ninja tricks and
> debug_backtrace, but it is very cumbersome and often hides your methods and
> properties from class signatures.
> >
> > Therefore I would propose adding a C# style "internal" keyword. (
> http://msdn.microsoft.com/en-us/library/7c5ka91b(v=vs.80).aspx )
> >
> > The idea is, simply, that functions, methods and classes marked as
> "internal" would only be accessible from within the namespace in which they
> are defined.
> >
> >
> > The "internal" keyword in C# restricts access to the same *assembly*. An
> assebly in .NET jargon is a .dll or a .exe, ie a package of code compiled
> by the same developper at once. As packages in PHP do not exist, or exist
> in some vague form (.phar, composer etc), I do not see how this keyword,
> with its original meaning, could find a place here.
> >
> > Namespaces are not restricted to the same develloper and anyone can add
> to them. Therefore, the meaning of the keyword would be totally different
> from that of C#.
> >
> >
> >
> >
> > For example the following class, "namespace Framework; internal class
> Something {}", would only be visible from within the "Framework" namespace.
> >
> > I have a hunch that this would be relatively easy to implement.
> >
> > If noone objects I would attempt to create a patch and an RFC.
> >
> > What do you think?
> >
> >
> > -Jens Riisom Schultz
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
--
github.com/KingCrunch
