I would like to write an RFC for the addition of an internal keyword View as Markdown

2013/2/27 Steve Clay steve@mrclay.org

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 API,
but if they
exist, I would want to call them if I know what I'm doing. I think it
would be useful if
phpdoc had an @internal tag so that IDEs could highlight places where you
use internal
parts of library.

Agreed, IDE/phpDoc is the place for a solution (and I do recognize that
there is some need here).

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 visibility" here: "@access private" comes from
old PHP4-days, where the DocComment must know the visibility, because the
method itself didn't
b) Most doc-tools are able to generate developer-docs, which usually
contain all protected and private elements. This "hidden element" will
appear as regular private method there. Can be confusing I think :)

There's already a way to tightly control access: embrace OOP and eliminate
statically accessible APIs (global vars/funcs and static props/methods)
that you don't want people calling. You don't actually need them. Although
closures helped too, PHP gained true information hiding in 5.0 with
"private".

I agree

Steve Clay

http://www.mrclay.org/

--

--
github.com/KingCrunch

2013/2/28 Jens Riisom Schultz ibmurai@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 linepogl@gmail.com
wrote:

Hello,

2013/2/27 Jens Riisom Schultz ibmurai@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

--
github.com/KingCrunch

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 namespace can only be accessed from methods
or functions inside the same namespace, or in ancestor namespaces.

E.g., if \Foo\Internal\ is protected, access of its classes/functions must originate from
classes/functions defined in \Foo, \Foo\Internal, or \Foo\Internal*.

This would allow something like nested classes, but obviously with a lot more flexibility.

In practice, plugin code sitting in, say, \MyPlugin\ could freely access
\Framework\SomeClass, but not \Framework\Internal\SomeClass.

I see some value there, but there's tons of questions remaining and how to to implement
the damn thing...

Steve Clay

http://www.mrclay.org/

• 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.