Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41497
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.92.172 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:references;
        b=qtzwYZHqs1DdpW67amCKHDgRmQr40D6V0CIk7obwsaYDB1OB4YH7gaAGo3jEpNxg3r
         UfVzcyxpymQP/CFAqirxaYI3Q6MiY76mQbqVg8Cxfm0RdpkmfizY/yiFZZbDRkieIRXJ
         EeaQVLjnXde33k/W+abtigUObFkteNVFFj+Fc=
Message-ID: <9b3df6a50810280012udd7946dh798b544cf9fd65ec@mail.gmail.com>
Date: Tue, 28 Oct 2008 09:12:51 +0200
To: Josh <josh.sickmate@gmail.com>
Cc: "Stan Vassilev | FM" <sv_forums@fmethod.com>, internals@lists.php.net
In-Reply-To: <6fef9b880810271958j6145ae02i125853adefaec9a3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_38515_63281.1225177971960"
References: <69907CB6763C4164A1AE82D659B80286@pc>
	 <6fef9b880810271958j6145ae02i125853adefaec9a3@mail.gmail.com>
Subject: Re: [PHP-DEV] Clarifying the resolution rules
From: arvids.godjuks@gmail.com ("Arvids Godjuks")

------=_Part_38515_63281.1225177971960
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I totally agree with Josh, same argument - resolving to global resources
should be by default, so we don't need to rewrite a lot of code, witch we
want to namespace. Namespaced functions will be called far less in code then
global ones.

2008/10/28 Josh <josh.sickmate@gmail.com>

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

------=_Part_38515_63281.1225177971960--