Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37657
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain gmail.com does not designate 204.127.217.103 as permitted sender)
Message-ID: <482B9F96.7050908@gmail.com>
Date: Wed, 14 May 2008 22:27:34 -0400
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: Stan Vassilev | FM <sv_forums@fmethod.com>
CC: internals@lists.php.net
References: <B3463B2BB0DD4F129EF274EA1DA1135F@pc>
In-Reply-To: <B3463B2BB0DD4F129EF274EA1DA1135F@pc>
Content-Type: text/plain; charset=windows-1251; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: 5.3 Namespace resolution rules suggestions
From: jrhernandez05@gmail.com (Jessie Hernandez)

Hi Stan,

I made a proposal and patch a few months ago at 
http://news.php.net/php.internals/34097, which Julian later adapted to a 
more recent version of PHP 5.3 at the time at 
http://news.php.net/php.internals/36822 (don't know if the patch still 
applies cleanly).

Unfortunately I haven't received many comments on the patch nor any 
reasons on why it shouldn't be merged. Let me know what you think of the 
resolution rules I proposed.


-- 

Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)


Stan Vassilev | FM wrote:
> 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 
> 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. 
> 
> 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 
> things.
> 2. Drop-in replacements for internal functionality won't work in namespace 
> context.
> 3. Problems when internal functions/classes start showing up in namespaces 
> in the future.
> 4. Performance hit, as more things need to be resolved at runtime that it's 
> needed.
> 
> Please give me your feedback and use cases.
> 
> Regards,
> Stan Vassilev