Jessie Hernandez wrote:
I thought global names were considered in the patch, but now that I
re-read Dmitry's post, only symbols in the namespace and internal
symbols are considered.
I read through most of the posts regarding namespaces, but could not
find a reason why global names are not l
Sam Barrow wrote:
> I agree with this 100%, is this something that could be changed? I don't
> see a reason behind it.
>
> On Sun, 2007-12-09 at 16:24 -0500, Jessie Hernandez wrote:
>
>> internal class/function with the same name.
>>
>> Dmitry, what's the reason this lookup logic wasn't used in
I agree with this 100%, is this something that could be changed? I don't
see a reason behind it.
On Sun, 2007-12-09 at 16:24 -0500, Jessie Hernandez wrote:
>
> internal class/function with the same name.
>
> Dmitry, what's the reason this lookup logic wasn't used in your patch?
>
--
PHP Inter
I thought global names were considered in the patch, but now that I
re-read Dmitry's post, only symbols in the namespace and internal
symbols are considered.
I read through most of the posts regarding namespaces, but could not
find a reason why global names are not looked up. Classes/functions
Jessie Hernandez wrote:
> Hi Greg,
>
> How about this: any non-namespaced file that uses "use" statements is
> implicitly put into the __php__ namespace (or whatever other name is
> chosen, or having the namespace name be the path of the file)? With
> this, "use" will never import any symbols into
Hi Greg,
How about this: any non-namespaced file that uses "use" statements is
implicitly put into the __php__ namespace (or whatever other name is
chosen, or having the namespace name be the path of the file)? With
this, "use" will never import any symbols into the global namespace.
Regard
Matthias Pigulla wrote:
>> Von: Gregory Beaver [mailto:[EMAIL PROTECTED]
>
>> Exactly - which is why you should never put classes, functions or
>> constants in the __php__ namespace. The convention I am proposing
>> is to only use __php__ for code that *uses* re-usable components,
>> not *declar
In C++, STD was just a normal namespace with some classes and functions
in it, you didn't have to say "use std" unless you wanted to use
functions in the std namespace.
The "php::" namespace could just be a container for all of the functions
and classes that are currently thrown into the global na
Hi Matthias,
Let alone __php__. If you just put all of your code into namespace Mylib,
you're not safe because according to the name resolution rules, internal
classes come after imported ones but before trying to find classes in the
current namespace.
I'd missed that :-( and from what I gathe
On Friday 07 December 2007, Gregory Beaver wrote:
> > If new, future core extensions showed up in a reserved PHP::
> > namespace, you would be >:-).
>
> Exactly - which is why you should never put classes, functions or
> constants in the __php__ namespace. The convention I am proposing is to
> on
> Von: Gregory Beaver [mailto:[EMAIL PROTECTED]
> Exactly - which is why you should never put classes, functions or
> constants in the __php__ namespace. The convention I am proposing is
> to
> only use __php__ for code that *uses* re-usable components, not
> *declares* them.
Let alone __php__.
Hi Greg,
1) recommend all global non-namespaced code that wishes to import
namespaced code via "use Namespace::Classname" add a "namespace
__php__;" at the top of the file, and that the __php__ namespace be
reserved for use by end-user applications.
That answers my main concern, but I'd make i
On 07 December 2007 17:36, Gregory Beaver wrote:
> The suggestion to make "namespace __php__;" implicit is very
> interesting, but would defeat its purpose, which is to separate
> declarations from use.
Oh, I missed that little wrinkle -- I did say I was only skimming! I guess it
could still be
Matthias Pigulla wrote:
>> 1) recommend all global non-namespaced code that wishes to import
>> namespaced code via "use Namespace::Classname" add a "namespace
>> __php__;" at the top of the file, and that the __php__ namespace be
>> reserved for use by end-user applications.
>
>
>> 5) namespa
On Thu, 6 Dec 2007, Gregory Beaver wrote:
> I've been thinking a *lot* about your provocative email in the past
> couple of days, and have come to a different conclusion from my original
> reply (which, as a reminder stated I saw no problem with removing
> namespaces as long as we kept the import
I agree with everything here, especially the solution to multiple
namespaces per file (allow but discourage), but i don't agree with the
__php__ namespace. If any separation of core php and extensions into
namespaces happens, it should be kept as simple as possible, with root
namespaces like "php::
Great work!
+1 from me for your proposals, too!
Roman
On Dec 7, 2007, at 2:36 AM, Gregory Beaver wrote:
Hi Derick,
I've been thinking a *lot* about your provocative email in the past
couple of days, and have come to a different conclusion from my
original
reply (which, as a reminder state
On 07 December 2007 01:36, Gregory Beaver wrote:
[...snip...]
> In other words, 1 line of code is needed to take advantage of
> namespace's full protection and ability to import conflicting class
> names into the "global" (in this case unqualified, not
> containing :: in
> the name) scope, while
> 1) recommend all global non-namespaced code that wishes to import
> namespaced code via "use Namespace::Classname" add a "namespace
> __php__;" at the top of the file, and that the __php__ namespace be
> reserved for use by end-user applications.
> 5) namespaces provide these benefits that are
Hi Greg,
I'm speechless. All of your points are sound and you've obviously done
your homework, here. I agree with Ken in that you've gone above and
beyond on the research and arguments you've presented here.
Excellent work and a hearty +1 to all of your points.
Jeremy
Gregory Beaver wrote:
PROTECTED]
> Sent: Thursday, December 06, 2007 5:36 PM
> To: Derick Rethans
> Cc: PHP Developers Mailing List
> Subject: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
>
> Hi Derick,
>
> I've been thinking a *lot* about your provocative email in the past
> co
Holy wow. That was fantastic! Not to downplay anything that Stas and the
other developers have done -- because let's face it, they've done a
fantastic job themselves -- you have definitely risen above and beyond the
call of duty and really come up with some very compelling counter-arguments.
This r
Hi Derick,
I've been thinking a *lot* about your provocative email in the past
couple of days, and have come to a different conclusion from my original
reply (which, as a reminder stated I saw no problem with removing
namespaces as long as we kept the import facility to alias classes via
use). Af
23 matches
Mail list logo
