Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41496
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.92.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=v4v6jnkkL7FDkn0kRdntY0tsf7or/RYduIaqd+70M2Bu+shQvF2lT4in43Jv7GMw6d
         CsHSEnI3pInaKgCJdx8SmYY6bo7M+49cYhhbKBqtHHE6ebMMxYKrQYqRk03ARExdoYwD
         xGEwIhNx+ZQDCCZGp8h1SK5J1477TTJNWdVZU=
Message-ID: <6fef9b880810271958j6145ae02i125853adefaec9a3@mail.gmail.com>
Date: Tue, 28 Oct 2008 13:28:18 +1030
To: "Stan Vassilev | FM" <sv_forums@fmethod.com>
Cc: internals@lists.php.net
In-Reply-To: <69907CB6763C4164A1AE82D659B80286@pc>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <69907CB6763C4164A1AE82D659B80286@pc>
Subject: Re: [PHP-DEV] Clarifying the resolution rules
From: josh.sickmate@gmail.com (Josh)

Hey,

I think that using \ to prefix global symbols in namespaces would be
quite dumb. It would feel counter-intuitive because then if your
coding you would need to think to yourself, "am I in a namespace?",
thus increasing the chance for simple errors. It would be incedibly
annoying when writing php libraries, because all of the library code
would be in namespaces, so you would need to prefix \ in front of
_every single_ function call in your library.

A change like this will also partially break code - rather than users
just appending 'namespace' at the beginning of every code file, they
would also need to update all global function calls. History has shown
us that breaking code (e.g. PHP4 - PHP5) slows adoption of new
versions.

Just my 2 cents.
Josh


On Mon, Oct 27, 2008 at 10:06 PM, Stan Vassilev | FM
<sv_forums@fmethod.com> wrote:
> Hi,
>
>
> Now that we have a separator, it's time to clarify what happened to the resolution order for functions and classes, which if I read Greg's messages, is still not clearly defined.
>
> 1) I think we've established that autoloading + fallback for classes is unworkable, as it either causes excessive autoload triggering, or alternatively allows internal classes to override unloaded but to-be-autoloaded namespaced classes. Then why is it still under consideration?
>
> 2) Making the backslash optional for internal functions means popular drop-in replacements for internal functions and extensions in global space, which work today, will break in a namespace, examples: libcurlemu. Also check any comments on PECL functions on php.net, and you'll see a myriad of drop-in replacements people use today.
>
> Also, for those who want to automatically convert their internal functions to backslash prefix for use in namespaces, you can use this quick snippet I wrote (works in 5.2.x too):
>
> http://pastebin.com/f13125acd
>
> I don't make guarantees it's perfect, but it can be improved and given to people as a porting aid.
>
> Opinions about how disruptive a mandatory backslash for global symbols *in namespaces* would be, are welcome. Keep in mind that making the backslash optional will lead to code breakage (such as for above drop-in replacements, class autoloading etc.) and slower performance (runtime resolution of function calls).
>
> Think of it as file paths. When you're inside a directory you need to prefix your path with "/" (eg "\") to refer to the root, but you don't need to do that when you're in the root directory.
>
> Regards,
> Stan Vassilev