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 to the class defined in \Framework?
What will happen in the following case:
namespace \Framework
internal class Foobar {}
namespace \Framework
class NotInternal {
public static function getFoobarInstance() {
return new Foobar();
}
}
Now a class in a completely different namespace can get an instance of
the "internal" \Framework\Foobar class. Now you could argue that this
violates the contract of the Foobar class by exposing it (or its
instances) to other namespaces - but at the same time you can argue that
a programmer should never call undocumented framework methods.
> "Often, when writing frameworks, you need to make public or protected
functionality or classes which should only be called from inside the
framework."
Here I'd like to throw "Design by Contract" at you:
http://en.wikipedia.org/wiki/Design_by_contract
Cheers,
Fabian
On 02/28/2013 07:56 AM, Jens Riisom Schultz wrote:
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.
* 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.
* 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?
* 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();
}
}
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();
?>
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
