Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66313
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain me.com designates 17.158.232.237 as permitted sender)
Content-type: multipart/alternative;
 boundary="Apple-Mail=_F20FF313-3A62-41A5-B4AE-48FCF60BC4D9"
Message-ID: <7E088EEC-ACB7-4977-BE00-CEA17ABD6EC3@me.com>
MIME-version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Date: Thu, 28 Feb 2013 07:56:54 +0100
References: <AB950117-17A2-4729-8CB0-0C5CACE0B20C@me.com>
 <CAMyk_AbRpFBnNKX3hh=dzoB_RTd1mGN5Aven9pe58C_XNF4Ezw@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
In-reply-to:
 <CAMyk_AbRpFBnNKX3hh=dzoB_RTd1mGN5Aven9pe58C_XNF4Ezw@mail.gmail.com>
Subject: Re: [PHP-DEV] I would like to write an RFC for the addition of an
 internal keyword
From: ibmurai@me.com (Jens Riisom Schultz)

--Apple-Mail=_F20FF313-3A62-41A5-B4AE-48FCF60BC4D9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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 =3D new InternalClass();
		return $instance->doInternalStuff();
	}

	internal public static function internalStuffHelper() {}
}=20

internal class InternalClass {
	public function doInternalStuff() {
		return PublicAPIClass::internalStuffHelper();
	}
}

namespace NotTheFramework;

$instance =3D new \Framework\PublicAPIClass();
$instance->doStuff();

// You would not be able to do the following things:
use Framework\InternalClass;

$instance =3D 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 <linepogl@gmail.com> =
wrote:

> Hello,
>=20
> 2013/2/27 Jens Riisom Schultz <ibmurai@me.com>
> Hi,
>=20
> 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):
>=20
> 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.
>=20
> Therefore I would propose adding a C# style "internal" keyword. ( =
http://msdn.microsoft.com/en-us/library/7c5ka91b(v=3Dvs.80).aspx )
>=20
> 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.
>=20
>=20
> 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.
>=20
> 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#.
>=20
>=20
>=20
> =20
> For example the following class, "namespace Framework; internal class =
Something {}", would only be visible from within the "Framework" =
namespace.
>=20
> I have a hunch that this would be relatively easy to implement.
>=20
> If noone objects I would attempt to create a patch and an RFC.
>=20
> What do you think?
>=20
>=20
> -Jens Riisom Schultz
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20
>=20


--Apple-Mail=_F20FF313-3A62-41A5-B4AE-48FCF60BC4D9--