Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37654
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 69.16.228.148 cause and error)
Message-ID: <B3463B2BB0DD4F129EF274EA1DA1135F@pc>
To: <internals@lists.php.net>
Date: Wed, 14 May 2008 21:52:29 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001B_01C8B60C.CE025020"
Subject: 5.3 Namespace resolution rules suggestions
From: sv_forums@fmethod.com ("Stan Vassilev | FM")

------=_NextPart_000_001B_01C8B60C.CE025020
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable


Hi,

I'm looking at the current namespace resolution rules here:
http://www.php.net/manual/en/language.namespaces.rules.php

Something that bothers me is that for the first time in PHP we introduce =
a
hard difference in how internal functions and user functions are
resolved/called:

::foo(); // resolves as user function in global namespace
foo(); // can resolve as function in the current namespace, else as =
internal
function

Whether a function/class is internal is implementation detail that I =
believe
shouldn't be forced in such a fashion in user code.

It makes people to check/think whether a function is internal or not,
additionally to thinking about namespace scope. It's unneded complexity. =
If
you check the PHP manual comments, you'll notice people often introduce =
PHP
userspace equivalents to various functions and extensions, there's for
example a full PHP-only implementation of curl:
http://code.blitzaffe.com/pages/phpclasses/files/libcurl_emulator_52-7

There was also a wave of drop-in replacements for PHP5 function in PHP4, =
or
for example json_en/decode() drop-in for PHP 5.1 users who don't have =
the
PECL extension.

None of those will be possible in namespace scope in 5.3, and a =
developer
will need to have plenty of special cases in code or special factories, =
if
it's not known in advance whether a class/function will be internal or =
not.

To further convolute things, the drop-ins will work if *not* in =
namespace=20
context.

A second problem is one of future-proofing. Many of the procedural API-s =
in
PHP4 saw transition to OOP in PHP5. If namespaces have success and are
adopted widely, we may see new or existing internal functions make =
similar
transitions to being namespaced. This will leave "global internal" =
function
stick our like a sore thumb, as a solitary special case with specific
syntax, as opposed to all other cases we have.

A third problem is one of performance. Every time a developer calls an
internal function, an attempt will be made to resolve it to a user =
function
in the current namespace, and only then call the internal function. =
Typical
PHP code contains plenty of internal function calls, while I believe the
novelty of being able to transparently override intenral functions will =
wear
off quickly and be used quite sparingly (and quite likely be considered =
a
bad practice, leading to confusing code).

What I suggest:

::foo(); // to resolve a user or internal function in global namespace =
(in
namespace context)
foo(); // to only resolve at compile time, in the current namespace (in
namespace context)

Much simpler to understand, more future-proofed, faster (more cases can =
be
covered by compile-time resolution), and allows PHP drop-ins for
binary/internal functionality.=20

To recap, problems with the current approach that are resolved by what I =

suggest:

1. Exposing internal/user functions in userspace code as two different=20
things.
2. Drop-in replacements for internal functionality won't work in =
namespace=20
context.
3. Problems when internal functions/classes start showing up in =
namespaces=20
in the future.
4. Performance hit, as more things need to be resolved at runtime that =
it's=20
needed.

Please give me your feedback and use cases.

Regards,
Stan Vassilev
------=_NextPart_000_001B_01C8B60C.CE025020--