Re: [PHP-DEV] RFC: Dropping Namespace
On 04.12.2007, at 23:41, Steph Fox wrote: Can I just ask one thing? If namespace support is once again pulled before it sees the light of a release, can we _please_ document exactly what the problems were, loud and clear, and put the document somewhere people are likely to see it? Amen. I wish we would do that for every decision we make that was remotely controversial. Such summaries should link together all relevant posts with a short summary. This is what I was talking about before I left for Brazil. I think taking the approach to tag posts + then being able to write some commentary would be a good solution for this that could work out without too much reliance on a single person putting in a fixed amount of time per week. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
Greg, I've been thinking about this as well and I also concluded that #3 is the way to go. If I "use" a class with the same name as an internal one, then I want to reference that class, I don't care about the internal class, and I don't want an error either. If a new PHP internal class is added to the future, then having the option of overriding internal class names guarantees me that my code won't break in an upgrade. If at the time of writing my code, I know that I am "using" a class with the same name as an internal one, AND I need to use both, then I can alias the classes appropriately to avoid clashes, e.g. Zend/Exception.php test1.php test2.php Regards, Jessie Gregory Beaver wrote: Dangit, I wasn't finished when that sent (apparently Ctrl-S sends a message - I was trying to Ctrl-V to paste) Gregory Beaver wrote: Hi again, I am not sure this will make it through the noise *sigh* but I'll give a try :) Derick Rethans wrote: Hei, now some patches by Greg and Dmitry made it into CVS, some of the things in my mail have been resolved, however, we still need to come up with a solution to the 1st and most important issue: On Tue, 4 Dec 2007, Derick Rethans wrote: 1. As it is impossible to do "use XXX as NativeClass" we get to the point where we'd have to namespace new internal native classes otherwise we might introduce BC breaks. AFAIK, we've always said that PHP reserves the globals space for it's own use (see also: http://www.php.net/manual/en/userlandnaming.rules.php). In case we do add new classes (an example could be DateTimeSpan), they should of course follow the same format as already existing classes in the extension (DateTime, DateTimeZone). However introducing the new class DateTimeSpan might break people's code that do things like: feature versions of people would then show: Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument because the name is already in use. It would be silly to require to have to do this: - Create a class PHP::Date::TimeSpan - In your scripts: use PHP::Date::TimeSpan But with the current implementation, this seems to be the only non-BC breaking solution. If we chose *not* to require this silly namespacing of internal classes, users instead have to do this: Basically prefixing the classnames... This you can already do just fine without namespaces. I know Greg has some ideas with __php__ as recommendation, but I find it a bit clumsy still. Perhaps Greg can summarize how it will address the above issue? I've been thinking quite a bit about several suggestions (surprise surprise). First of all, Marcus Boerger suggested on IRC that "__php__" was not the best name, and proposed "__user__" as a more logical choice for the convention, which appeals to me more for the obvious reason that it doesn't have the chance of confusing with "PHP" or "php" should either of these be adopted by the core folks ever. I am going to use some shorthand. "internal class is used first" means this code: would use ::Exception unles hithere::Exception already exists. In my inimitable style, for the larger suggestions I've been thinking about I will list them: 1) having an implicit namespace for unnamespaced code 2) never accessing internal classes inside a namespace (tough to summarize I explain below) 3) allowing override of internal classes with "use" in the global scope 4) keep things the way they work now, and recommend using "namespace __user__" for userspace code. 1) having an implicit namespace for unnamespaced code = This is an interesting idea that will break autoloaders unless the implicit namespace is automatically stripped on a call to autoload, get_class() and reflection. Pros: use myNamespace::DateTimeZone as DateTimeZone; will always work as intended Cons: slight performance hit on every autoload caused by a strstr() check on classname for "__auto__::" and same hit on get_class(), ReflectionClass stuff large number of potential "oops" spots for the implicit namespace to slip into code and break everything horrendously. the patch would be huge and very dangerous for the above reason until kinks are worked out. doesn't solve the "internal class is used first" issue. 2) never accessing internal classes inside a namespace = This basically means changing the autoloading rules to the following (using the hithere namespace/Exception example from above): 1) does hithere::Exception exist? 2) if not, autoload it Pros: it is not necessary to "use hithere::classname" for every class you might autoload. 1 hash lookup reduced per autoloaded class (very minor performance gain, hash lookup is O(1). profiling might not even detect a difference.) Cons: to use internal classes, you would need to explicitly use ::Classname; for each of them. Code that does not use autoload wou
Re: [PHP-DEV] RFC: Dropping Namespace
Dangit, I wasn't finished when that sent (apparently Ctrl-S sends a
message - I was trying to Ctrl-V to paste)
Gregory Beaver wrote:
> Hi again,
>
> I am not sure this will make it through the noise *sigh* but I'll give a
> try :)
>
> Derick Rethans wrote:
>
>> Hei,
>>
>> now some patches by Greg and Dmitry made it into CVS, some of the things
>> in my mail have been resolved, however, we still need to come up with a
>> solution to the 1st and most important issue:
>>
>> On Tue, 4 Dec 2007, Derick Rethans wrote:
>>
>>
>>
>>> 1. As it is impossible to do "use XXX as NativeClass" we get to the
>>>point where we'd have to namespace new internal native classes
>>>otherwise we might introduce BC breaks. AFAIK, we've always said that
>>>PHP reserves the globals space for it's own use (see also:
>>>http://www.php.net/manual/en/userlandnaming.rules.php). In case we do
>>>add new classes (an example could be DateTimeSpan), they should of
>>>course follow the same format as already existing classes in the
>>>extension (DateTime, DateTimeZone). However introducing the new class
>>>DateTimeSpan might break people's code that do things like:
>>>
>>> >> use myNamespace::DateTimeZone as DateTimeZone;
>>> ?>
>>>
>>>feature versions of people would then show:
>>>
>>> Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument
>>> because the name is already in use.
>>>
>>>It would be silly to require to have to do this:
>>>
>>> - Create a class PHP::Date::TimeSpan
>>> - In your scripts:
>>> use PHP::Date::TimeSpan
>>>
>>> But with the current implementation, this seems to be the only non-BC
>>> breaking solution. If we chose *not* to require this silly namespacing
>>> of internal classes, users instead have to do this:
>>>
>>> >> use myNamespace::DateTimeZone as myDateTimeZone;
>>> ?>
>>>
>>> Basically prefixing the classnames... This you can already do just
>>> fine without namespaces.
>>>
>>>
>> I know Greg has some ideas with __php__ as recommendation, but I find it
>> a bit clumsy still. Perhaps Greg can summarize how it will address the
>> above issue?
>>
> I've been thinking quite a bit about several suggestions (surprise
> surprise). First of all, Marcus Boerger suggested on IRC that "__php__"
> was not the best name, and proposed "__user__" as a more logical choice
> for the convention, which appeals to me more for the obvious reason that
> it doesn't have the chance of confusing with "PHP" or "php" should
> either of these be adopted by the core folks ever.
>
> I am going to use some shorthand. "internal class is used first" means
> this code:
>
> namespace hithere;
> $a = new Exception('hi');
> ?>
>
> would use ::Exception unles hithere::Exception already exists.
>
> In my inimitable style, for the larger suggestions I've been thinking
> about I will list them:
>
> 1) having an implicit namespace for unnamespaced code
> 2) never accessing internal classes inside a namespace (tough to
> summarize I explain below)
> 3) allowing override of internal classes with "use" in the global scope
> 4) keep things the way they work now, and recommend using "namespace
> __user__" for userspace code.
>
> 1) having an implicit namespace for unnamespaced code
> =
>
>
> This is an interesting idea that will break autoloaders unless the
> implicit namespace is automatically stripped on a call to autoload,
> get_class() and reflection.
>
> Pros:
> use myNamespace::DateTimeZone as DateTimeZone; will always work as intended
>
> Cons:
> slight performance hit on every autoload caused by a strstr() check on
> classname for "__auto__::" and same hit on get_class(), ReflectionClass
> stuff
> large number of potential "oops" spots for the implicit namespace to
> slip into code and break everything horrendously.
> the patch would be huge and very dangerous for the above reason until
> kinks are worked out.
> doesn't solve the "internal class is used first" issue.
>
> 2) never accessing internal classes inside a namespace
> =
>
> This basically means changing the autoloading rules to the following
> (using the hithere namespace/Exception example from above):
>
> 1) does hithere::Exception exist?
> 2) if not, autoload it
>
> Pros:
> it is not necessary to "use hithere::classname" for every class you
> might autoload.
> 1 hash lookup reduced per autoloaded class (very minor performance gain,
> hash lookup is O(1). profiling might not even detect a difference.)
>
> Cons:
> to use internal classes, you would need to explicitly use ::Classname;
> for each of them.
> Code that does not use autoload would *also* have to explicitly use
> ::Classname;
> code that uses internal classes that wishes to become namespaced would
> need to go through and figure out which internal classes are used and
> add "use ::Classname" at the top of the file, making porting to
> namespaces
Re: [PHP-DEV] RFC: Dropping Namespace
Hi again, I am not sure this will make it through the noise *sigh* but I'll give a try :) Derick Rethans wrote: > Hei, > > now some patches by Greg and Dmitry made it into CVS, some of the things > in my mail have been resolved, however, we still need to come up with a > solution to the 1st and most important issue: > > On Tue, 4 Dec 2007, Derick Rethans wrote: > > >> 1. As it is impossible to do "use XXX as NativeClass" we get to the >>point where we'd have to namespace new internal native classes >>otherwise we might introduce BC breaks. AFAIK, we've always said that >>PHP reserves the globals space for it's own use (see also: >>http://www.php.net/manual/en/userlandnaming.rules.php). In case we do >>add new classes (an example could be DateTimeSpan), they should of >>course follow the same format as already existing classes in the >>extension (DateTime, DateTimeZone). However introducing the new class >>DateTimeSpan might break people's code that do things like: >> >> > use myNamespace::DateTimeZone as DateTimeZone; >> ?> >> >>feature versions of people would then show: >> >> Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument >> because the name is already in use. >> >>It would be silly to require to have to do this: >> >> - Create a class PHP::Date::TimeSpan >> - In your scripts: >>use PHP::Date::TimeSpan >> >> But with the current implementation, this seems to be the only non-BC >> breaking solution. If we chose *not* to require this silly namespacing >> of internal classes, users instead have to do this: >> >> > use myNamespace::DateTimeZone as myDateTimeZone; >> ?> >> >> Basically prefixing the classnames... This you can already do just >> fine without namespaces. >> > > I know Greg has some ideas with __php__ as recommendation, but I find it > a bit clumsy still. Perhaps Greg can summarize how it will address the > above issue? I've been thinking quite a bit about several suggestions (surprise surprise). First of all, Marcus Boerger suggested on IRC that "__php__" was not the best name, and proposed "__user__" as a more logical choice for the convention, which appeals to me more for the obvious reason that it doesn't have the chance of confusing with "PHP" or "php" should either of these be adopted by the core folks ever. I am going to use some shorthand. "internal class is used first" means this code: would use ::Exception unles hithere::Exception already exists. In my inimitable style, for the larger suggestions I've been thinking about I will list them: 1) having an implicit namespace for unnamespaced code 2) never accessing internal classes inside a namespace (tough to summarize I explain below) 3) allowing override of internal classes with "use" in the global scope 4) keep things the way they work now, and recommend using "namespace __user__" for userspace code. 1) having an implicit namespace for unnamespaced code This is an interesting idea that will break autoloaders unless the implicit namespace is automatically stripped on a call to autoload, get_class() and reflection. Pros: use myNamespace::DateTimeZone as DateTimeZone; will always work as intended Cons: slight performance hit on every autoload caused by a strstr() check on classname for "__auto__::" and same hit on get_class(), ReflectionClass stuff large number of potential "oops" spots for the implicit namespace to slip into code and break everything horrendously. the patch would be huge and very dangerous for the above reason until kinks are worked out. doesn't solve the "internal class is used first" issue. 2) never accessing internal classes inside a namespace = This basically means changing the autoloading rules to the following (using the hithere namespace/Exception example from above): 1) does hithere::Exception exist? 2) if not, autoload it Pros: it is not necessary to "use hithere::classname" for every class you might autoload. 1 hash lookup reduced per autoloaded class (very minor performance gain, hash lookup is O(1). profiling might not even detect a difference.) Cons: to use internal classes, you would need to explicitly use ::Classname; for each of them. Code that does not use autoload would *also* have to explicitly use ::Classname; code that uses internal classes that wishes to become namespaced would need to go through and figure out which internal classes are used and add "use ::Classname" at the top of the file, making porting to namespaces much more difficult. 3) allowing override of internal classes with "use" in the global scope = This would be surprisingly easy to implement, currently the only thing preventing it from happening is a 5-10 line check in zend_do_use() to see if the name requested would conflict with an internal class. Remove that check and it becomes possible Pros: Derick's main issue goes away, name co
Re: [PHP-DEV] RFC: Dropping Namespace
Hi Derick, Now, you cannot override existing classes with "use" statement. However inside a namespace you don't have internal classes and "use" works just fine. I think it is clear decision. If you like to override internal classes just write your code in your own namespace. Allowing class overriding is possible from technical point of view (it is disabled on purpose), but it'll give more mess than advantage. Thanks. Dmitry. Derick Rethans wrote: Hei, now some patches by Greg and Dmitry made it into CVS, some of the things in my mail have been resolved, however, we still need to come up with a solution to the 1st and most important issue: On Tue, 4 Dec 2007, Derick Rethans wrote: 1. As it is impossible to do "use XXX as NativeClass" we get to the point where we'd have to namespace new internal native classes otherwise we might introduce BC breaks. AFAIK, we've always said that PHP reserves the globals space for it's own use (see also: http://www.php.net/manual/en/userlandnaming.rules.php). In case we do add new classes (an example could be DateTimeSpan), they should of course follow the same format as already existing classes in the extension (DateTime, DateTimeZone). However introducing the new class DateTimeSpan might break people's code that do things like: feature versions of people would then show: Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument because the name is already in use. It would be silly to require to have to do this: - Create a class PHP::Date::TimeSpan - In your scripts: use PHP::Date::TimeSpan But with the current implementation, this seems to be the only non-BC breaking solution. If we chose *not* to require this silly namespacing of internal classes, users instead have to do this: Basically prefixing the classnames... This you can already do just fine without namespaces. I know Greg has some ideas with __php__ as recommendation, but I find it a bit clumsy still. Perhaps Greg can summarize how it will address the above issue? regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
Hei, now some patches by Greg and Dmitry made it into CVS, some of the things in my mail have been resolved, however, we still need to come up with a solution to the 1st and most important issue: On Tue, 4 Dec 2007, Derick Rethans wrote: > 1. As it is impossible to do "use XXX as NativeClass" we get to the >point where we'd have to namespace new internal native classes >otherwise we might introduce BC breaks. AFAIK, we've always said that >PHP reserves the globals space for it's own use (see also: >http://www.php.net/manual/en/userlandnaming.rules.php). In case we do >add new classes (an example could be DateTimeSpan), they should of >course follow the same format as already existing classes in the >extension (DateTime, DateTimeZone). However introducing the new class >DateTimeSpan might break people's code that do things like: > > use myNamespace::DateTimeZone as DateTimeZone; > ?> > >feature versions of people would then show: > > Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument > because the name is already in use. > >It would be silly to require to have to do this: > > - Create a class PHP::Date::TimeSpan > - In your scripts: > use PHP::Date::TimeSpan > > But with the current implementation, this seems to be the only non-BC > breaking solution. If we chose *not* to require this silly namespacing > of internal classes, users instead have to do this: > > use myNamespace::DateTimeZone as myDateTimeZone; > ?> > > Basically prefixing the classnames... This you can already do just > fine without namespaces. I know Greg has some ideas with __php__ as recommendation, but I find it a bit clumsy still. Perhaps Greg can summarize how it will address the above issue? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
Hi! Especially in a framework context there a lot of options how you can make things more convenient, with convention over configuration for example. In the end it might turn out that a developer doesn't have to type class names that often anymore and the length of such a name gets less important. And I think typing couldn't be a deciding factor, almost every IDE/editor provide code competition. Best Regards, Felhő -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
Hi Nate, Only if you insist on *not* using the namespaces to solve collision problems. For the 1001th time - you can not expect to put all names into global space and have the language by some magic to sort it out and go both ways. One name can mean only one thing, namespaces or not. Namespaces just allow you more convenient rules for defining what name means what thing. I would like to second this notion. There are those who would say that the global namespace is for the use of PHP itself. I would disagree heartily, PHP as a language is built to serve the developer who is using it. They should decide what exists in the global namespace. I'm firmly in the 'global namespace is for the use of PHP itself' camp. Why? Because it gives users the choice of totally ignoring namespace support if they don't want to use it, and because allowing user code to define classnames and functions in the global space via import/use (as opposed to by default) has a huge potential for difficult-to-debug misuse. If people want to be able to alias stuff they should be forced to namespace their code. When I write a library I will often create functions/classes/variables that have no business being used outside my library. So I don't see the need to make the names longer just so I don't collide with someone else's internal variables/classes/functions. Fine, so namespace it. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
I agree, I also see this as critical in large applications. The current
implementation may have some problems, yes, but it's not hurting anyone
who's not using namespaces.
The minor issues around namespaces can be worked out in due time, but I
think it would be a huge mistake to drop the whole idea. Most
programming languages have some type of namespace implementation, there
is obviously some usefulness to it.
My personal opinion:
- Allow multiple namespaces per file (mostly for bundling). Personally,
in my application, this cuts execution time literally from .18 seconds
to about .04. Microseconds, but with alot of users this would definitely
be beneficial.
- Braces or declarations like the current, it doesn't matter. However I
think it is important to be able to use the same namespace in different
blocks, allowing functions to be declared under the same namespace in
different files. Declarations like it is now seem fine.
- Some type of import X as Y statement might be useful, but would be
very easy to abuse. Some people would import too much and defeat the
entire purpose of namespaces. I don't have much of an opinion on this.
In essence, I believe keeping namespaces is a necessity. The only useful
feature I have seen people talking about is multiple namespaces per
file. I also saw a patch on here for it (only about 5 lines of actual
code changed by the way), I set it up on PHP 5.3 and I've been using it
for about 8 hours of constant development and testing with no problems
whatsoever.
On Wed, 2007-12-05 at 14:10 -0600, Nate Gordon wrote:
> On Dec 5, 2007 12:04 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > > collision problems that class naming and function naming have. Only
> >
> > Only if you insist on *not* using the namespaces to solve collision
> > problems. For the 1001th time - you can not expect to put all names into
> > global space and have the language by some magic to sort it out and go
> > both ways. One name can mean only one thing, namespaces or not.
> > Namespaces just allow you more convenient rules for defining what name
> > means what thing.
>
> I would like to second this notion. There are those who would say
> that the global namespace is for the use of PHP itself. I would
> disagree heartily, PHP as a language is built to serve the developer
> who is using it. They should decide what exists in the global
> namespace.
>
> When I write a library I will often create functions/classes/variables
> that have no business being used outside my library. So I don't see
> the need to make the names longer just so I don't collide with someone
> else's internal variables/classes/functions.
>
> This paves the way for doing much more advanced things with packages
> and run-time loading of code (which I know some people will think
> isn't good).
>
> Of all the namespace talk I've heard, the only part I disagree with is:
>
> use Foo::Bar as OtherBar;
>
> This seems like a maintainability nightmare to me as well as having
> well having some possible BC issues long-term. If you don't like
> someone's class name that much that you have to alias it then just
> make your own wrapper class:
>
> class OtherBar extends Foo::Bar {}
>
> Its not like it is that many more characters to write.
>
> So if we have to wait until PHP 6 to get this right, then so be it. I
> just see this as being critical to the future of enterprise/large
> scale PHP and don't want to see it die.
>
>
> --
> -Nathan Gordon
>
> If the database server goes down and there is no code to hear it, does
> it really go down?
> :wq
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
And I already do that within my code without namespaces. You can also do anything in code without classes, so what? With classes it works better, and with namespaces it is yet better. Yes, but the main push for namespaces is to solve the problem of colliding names. You can not solve this problem in a way you present it. It's just contradictory. The main push for namespaces is to help solving it in the right way - by avoiding single-space problem. And as I said before, I'm not for or against namespaces. I still stand by the phrase that they are sugar. obviously, given the lengths of Well, OK, so that's your opinion. I disagree with it. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
On Wed, 2007-12-05 at 10:04 -0800, Stanislav Malyshev wrote: > > > namespaces bring to the table beyond that, is the ability to > > shorthand the class names within the namespace... as I said candy > > coating. > > You can say it as many times as you like, it doesn't make it true. It > is the capability that enables one to simplify the code by avoiding > spelling out the full name every time. Ummm, "avoiding spelling out the full name every time" is the same as shorthanding the class name (or for more clarity, the fully resolved class name given the namespaces exist). And I already do that within my code without namespaces. > > everyone had named their classes and functions with appropriate > prefixes then this would be a non-issue. Seriously, how were so many > people so > > As I said, namespaces is not only names, so it is not true. Yes, but the main push for namespaces is to solve the problem of colliding names. > > Hope this clears up your confusion, although I doubt you were > > particularly confused. > > I wasn't confused, I was surprised that after all the explanations > people still make such strange claims which have nothing to do with > what namespaces really are. And as I said before, I'm not for or against namespaces. I still stand by the phrase that they are sugar. obviously, given the lengths of arguments and discussions about them on this list, they don't seem to be contributing in particular to the KISS principle. Cheers, Rob. -- ... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
On Dec 5, 2007 12:04 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > collision problems that class naming and function naming have. Only
>
> Only if you insist on *not* using the namespaces to solve collision
> problems. For the 1001th time - you can not expect to put all names into
> global space and have the language by some magic to sort it out and go
> both ways. One name can mean only one thing, namespaces or not.
> Namespaces just allow you more convenient rules for defining what name
> means what thing.
I would like to second this notion. There are those who would say
that the global namespace is for the use of PHP itself. I would
disagree heartily, PHP as a language is built to serve the developer
who is using it. They should decide what exists in the global
namespace.
When I write a library I will often create functions/classes/variables
that have no business being used outside my library. So I don't see
the need to make the names longer just so I don't collide with someone
else's internal variables/classes/functions.
This paves the way for doing much more advanced things with packages
and run-time loading of code (which I know some people will think
isn't good).
Of all the namespace talk I've heard, the only part I disagree with is:
use Foo::Bar as OtherBar;
This seems like a maintainability nightmare to me as well as having
well having some possible BC issues long-term. If you don't like
someone's class name that much that you have to alias it then just
make your own wrapper class:
class OtherBar extends Foo::Bar {}
Its not like it is that many more characters to write.
So if we have to wait until PHP 6 to get this right, then so be it. I
just see this as being critical to the future of enterprise/large
scale PHP and don't want to see it die.
--
-Nathan Gordon
If the database server goes down and there is no code to hear it, does
it really go down?
:wq
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
+1. Maybe PHP 6, as Sebastian suggested. David Am 05.12.2007 um 19:22 schrieb Jochem Maas: +1 for putting namespaces on the backburner and taking the time to get it 100% right ... Stanislav Malyshev wrote: some people like a "misguided" implementation of namespaces. The idea of namespaces is to prevent collisions in USER land code, not turning internal PHP classes into a pile of goo. Yes, idea of namespaces is not to turn PHP classes into a pile of goo. But what's your point? I don't quite understand why allowing multiple namespaces is such a big issue, however - it won't solve the naming collision issue. I'm sorry, I don't understand what you mean by "multiple namespaces" - multiple namespaces per file? I object to allowing it for reasons having absolutely nothing to do with naming collisions, as anybody bothering to actually read what I wrote would immediately know. this implies that your objections to multiple namespaces per file is valid whereas objections to the limitation are invalid. apparently people keep 'flogging this horse to death' because they are not convinced by your wisdom with regard to this decision - they may be idiots (me included) but they are the majority of your users, so it seems. That's because namespaces are not executable blocks. Neither are classes. Your point being? that therefore your argue that "namespaces are not executable blocks" doesn't hold up unless your willing to state the inconsistency is one of your design goals. No, but, do you really need to have such long names? And besides that, Yes. Such names are hard fact of life, I have seen them in many applications and libraries, and I have heard developers to complain about it. developers will complain, it's in their blood, nothing anyone will ever produce will change that ... somewhere in the future when all code is created without the intervention of man .. even then there will still be a compiler complaining. you *have* to keep repeating them in every file you'd want to use them - Once per file, yes. Much better than having to spell out all the long names every time. Just saying "Yes, they are" is not a very good argument - actually, it's not an argument at all. No more and no less than "I wonder if they are useful, let's just delete them". actually that is not true - a halfbaked concept is pretty much garanteed to give you and the users of your product more headaches than no implementation at all. and once the genie is out of the bottle your stuck with it - with all the BC implications of having to support functionality people would rather see changed. besides possibly having to type a little less, there seems to be nothing namespaces would give us [in it's current form] that we cannot achieve already ... with the bonus that users are currently not restricted in the way they organize/rollout their code, at least with regard to 'bundling' of files. Actually, it's exactly the opposite, as I avoid naming colissions (point 1), I don't need to import every class I want to use (point 2), and can group all my classes together in one file (point 3). Of course, if you don't want to hear about namespaces, nobody can force you. However, all of your points (avoiding naming collisions, not needing to import every class you want to use and ability to group classes together) is exactly how namespaces work right now. If you refuse to learn about it, it can't be helped, however that just means you deny yourself a very useful tool. conversly - when namespace functionality is released, every developer will be confronted with any problems they might bring with them, at some stage, because there will be third party code out there that uses namespaces (code which for the sake of argument one would be required to use under some circumstances). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Zülke [EMAIL PROTECTED] Tel: +49 (0)89 57 08 15 15 bitXtender GbR Paul-Heyse-Straße 6 80336 München -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
+1 for putting namespaces on the backburner and taking the time to get it 100% right ... Stanislav Malyshev wrote: >> some people like a "misguided" implementation of namespaces. The idea >> of namespaces is to prevent collisions in USER land code, not turning >> internal PHP classes into a pile of goo. > > Yes, idea of namespaces is not to turn PHP classes into a pile of goo. > But what's your point? > >> I don't quite understand why allowing multiple namespaces is such a >> big issue, however - it won't solve the naming collision issue. > > I'm sorry, I don't understand what you mean by "multiple namespaces" - > multiple namespaces per file? I object to allowing it for reasons having > absolutely nothing to do with naming collisions, as anybody bothering to > actually read what I wrote would immediately know. this implies that your objections to multiple namespaces per file is valid whereas objections to the limitation are invalid. apparently people keep 'flogging this horse to death' because they are not convinced by your wisdom with regard to this decision - they may be idiots (me included) but they are the majority of your users, so it seems. > >>> That's because namespaces are not executable blocks. >> >> Neither are classes. > > Your point being? that therefore your argue that "namespaces are not executable blocks" doesn't hold up unless your willing to state the inconsistency is one of your design goals. > >> No, but, do you really need to have such long names? And besides that, > > Yes. Such names are hard fact of life, I have seen them in many > applications and libraries, and I have heard developers to complain > about it. developers will complain, it's in their blood, nothing anyone will ever produce will change that ... somewhere in the future when all code is created without the intervention of man .. even then there will still be a compiler complaining. > >> you *have* to keep repeating them in every file you'd want to use them - > > Once per file, yes. Much better than having to spell out all the long > names every time. > > > Just saying "Yes, they are" is not a very good argument - actually, it's >> not an argument at all. > > No more and no less than "I wonder if they are useful, let's just delete > them". actually that is not true - a halfbaked concept is pretty much garanteed to give you and the users of your product more headaches than no implementation at all. and once the genie is out of the bottle your stuck with it - with all the BC implications of having to support functionality people would rather see changed. besides possibly having to type a little less, there seems to be nothing namespaces would give us [in it's current form] that we cannot achieve already ... with the bonus that users are currently not restricted in the way they organize/rollout their code, at least with regard to 'bundling' of files. > >> Actually, it's exactly the opposite, as I avoid naming colissions >> (point 1), I don't need to import every class I want to use (point 2), >> and can group all my classes together in one file (point 3). > > Of course, if you don't want to hear about namespaces, nobody can force > you. However, all of your points (avoiding naming collisions, not > needing to import every class you want to use and ability to group > classes together) is exactly how namespaces work right now. If you > refuse to learn about it, it can't be helped, however that just means > you deny yourself a very useful tool. conversly - when namespace functionality is released, every developer will be confronted with any problems they might bring with them, at some stage, because there will be third party code out there that uses namespaces (code which for the sake of argument one would be required to use under some circumstances). > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
2007/12/5, Robert Cummings <[EMAIL PROTECTED]>: > > On Wed, 2007-12-05 at 09:34 -0800, Stanislav Malyshev wrote: > > > Namespace support is for people who didn't name their > classes/functions > > > properly. > > > > Here's a claim so weird I don't know how to parse it. > > I think you're confusing parsing for grokking. Namespace support is > merely candy coating for naming conventions. Namespaces have the same > collision problems that class naming and function naming have. Only > confined to the name of the namespace itself. This is identical to using > a prefix when naming your classes or functions. The only thing > namespaces bring to the table beyond that, is the ability to shorthand > the class names within the namespace... as I said candy coating. If > everyone had named their classes and functions with appropriate prefixes > then this would be a non-issue. Seriously, how were so many people so > short-sighted to think that only they would ever call a class "Date". > There's only a few million other candidate developers out there with the > similar ideas. Sorry to intrude again, but that's not entirely true. As of now, PHP namespaces may be called just sugar coating for naming conventions, but, as I see it, they're just a first step towards a more complete implementation of namespaces, which means more granular control over class visibility and scope. This much enhances encapsulation on a broader level, which is a basic need for any proper OOP supporting language. In other words, without namespaces, we can't even start thinking about encapsulation at package level, we'll just have all our classes publicly available everywhere.
Re: [PHP-DEV] RFC: Dropping Namespace
Anyway, I'm not against namespaces but the way they are planned to be implemented currently I'm not really excited about them either. So you are proposing to improve them how? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
I think you're confusing parsing for grokking. Namespace support is merely candy coating for naming conventions. Namespaces have the same Yes, and PHP is merely a candy coating for shoving electrons around silicon chips. Makes as much sense. Yes, namespaces deal with naming. No, namespace in not just a naming convention - it is also the mechanics allowing to use these conventions consistently and conveniently. collision problems that class naming and function naming have. Only Only if you insist on *not* using the namespaces to solve collision problems. For the 1001th time - you can not expect to put all names into global space and have the language by some magic to sort it out and go both ways. One name can mean only one thing, namespaces or not. Namespaces just allow you more convenient rules for defining what name means what thing. confined to the name of the namespace itself. This is identical to using a prefix when naming your classes or functions. The only thing Only if you had auto-prefixing and aliasing with underscore prefixes. If you had, that would be exactly namespaces with _ as separator. I like :: better. namespaces bring to the table beyond that, is the ability to shorthand the class names within the namespace... as I said candy coating. If You can say it as many times as you like, it doesn't make it true. It is the capability that enables one to simplify the code by avoiding spelling out the full name every time. everyone had named their classes and functions with appropriate prefixes then this would be a non-issue. Seriously, how were so many people so As I said, namespaces is not only names, so it is not true. Hope this clears up your confusion, although I doubt you were particularly confused. I wasn't confused, I was surprised that after all the explanations people still make such strange claims which have nothing to do with what namespaces really are. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
Hi Larry, Am 05.12.2007 um 18:09 schrieb Larry Garfield: Finally, another important reason for us to not use namespaces is the lack of available refactoring tools. Imagine you want to rename a class "T3_Cool_Fancy_Stuff" to "T3_Cool_Fancy_Tool". A global search / replace and renaming the class file will usually do - if you use the full class name everywhere. However, just trying to search and replace "Stuff" will probably break your code. How can there be "available refactoring tools" that account for namespaces when released PHP doesn't have namespaces yet? yes, of course you're right, it's always a chicken-and-egg problem. I was talking from my PHP user's perspective here However, since I didn't stumble over any satisfying refactoring tool for PHP yet, I don't have much hope that this will change soon. Anyway, lack of tools is of course not an argument to add namespaces support or not. But it is one for using it or not. robert -- http://typo3.org/gimmefive http://buzz.typo3.org/people/robert-lemke/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
some people like a "misguided" implementation of namespaces. The idea of namespaces is to prevent collisions in USER land code, not turning internal PHP classes into a pile of goo. Yes, idea of namespaces is not to turn PHP classes into a pile of goo. But what's your point? I don't quite understand why allowing multiple namespaces is such a big issue, however - it won't solve the naming collision issue. I'm sorry, I don't understand what you mean by "multiple namespaces" - multiple namespaces per file? I object to allowing it for reasons having absolutely nothing to do with naming collisions, as anybody bothering to actually read what I wrote would immediately know. That's because namespaces are not executable blocks. Neither are classes. Your point being? No, but, do you really need to have such long names? And besides that, Yes. Such names are hard fact of life, I have seen them in many applications and libraries, and I have heard developers to complain about it. you *have* to keep repeating them in every file you'd want to use them - Once per file, yes. Much better than having to spell out all the long names every time. > Just saying "Yes, they are" is not a very good argument - actually, it's not an argument at all. No more and no less than "I wonder if they are useful, let's just delete them". Actually, it's exactly the opposite, as I avoid naming colissions (point 1), I don't need to import every class I want to use (point 2), and can group all my classes together in one file (point 3). Of course, if you don't want to hear about namespaces, nobody can force you. However, all of your points (avoiding naming collisions, not needing to import every class you want to use and ability to group classes together) is exactly how namespaces work right now. If you refuse to learn about it, it can't be helped, however that just means you deny yourself a very useful tool. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
On Wed, 2007-12-05 at 09:34 -0800, Stanislav Malyshev wrote: > > Namespace support is for people who didn't name their classes/functions > > properly. > > Here's a claim so weird I don't know how to parse it. I think you're confusing parsing for grokking. Namespace support is merely candy coating for naming conventions. Namespaces have the same collision problems that class naming and function naming have. Only confined to the name of the namespace itself. This is identical to using a prefix when naming your classes or functions. The only thing namespaces bring to the table beyond that, is the ability to shorthand the class names within the namespace... as I said candy coating. If everyone had named their classes and functions with appropriate prefixes then this would be a non-issue. Seriously, how were so many people so short-sighted to think that only they would ever call a class "Date". There's only a few million other candidate developers out there with the similar ideas. Hope this clears up your confusion, although I doubt you were particularly confused. Cheers, Rob. -- ... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
Hi Sam, Am 05.12.2007 um 14:51 schrieb Sam Barrow: Autoload would work exactly the same with namespaces, just do a str_replace and replace "::" with "_". hmm, and what about this (please correct me if I'm wrong): A search & replace of "Default" would replace both, T3::MyPackage::Controller::Default and T3::OtherPackage::Controller::Default - but they are not the same. The only way to refactor this would be by the help of a semantic-aware tool. Anyway, I'm not against namespaces but the way they are planned to be implemented currently I'm not really excited about them either. robert -- http://typo3.org/gimmefive http://buzz.typo3.org/people/robert-lemke/ PGP.sig Description: This is a digitally signed message part
Re: [PHP-DEV] RFC: Dropping Namespace
Namespace support is for people who didn't name their classes/functions properly. Here's a claim so weird I don't know how to parse it. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
On Wed, 5 Dec 2007 11:48:58 +0100, Robert Lemke <[EMAIL PROTECTED]> wrote: > Finally, another important reason for us to not use namespaces is the > lack of available refactoring tools. > Imagine you want to rename a class "T3_Cool_Fancy_Stuff" to > "T3_Cool_Fancy_Tool". A global search / replace > and renaming the class file will usually do - if you use the full > class name everywhere. However, just trying to > search and replace "Stuff" will probably break your code. How can there be "available refactoring tools" that account for namespaces when released PHP doesn't have namespaces yet? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
On Wed, 5 Dec 2007 09:55:40 +0100 (CET), Derick Rethans <[EMAIL PROTECTED]>
wrote:
> On Tue, 4 Dec 2007, Larry Garfield wrote:
>
>> 1) "use MyDate as DateTime". I believe Greg pointed out the solution
> here.
>> When PHP 5.5 is released and adds its own Whatever class, you just do
> the
>> following:
>>
>> namespace me;
>> use Whatever as LegacyWhatever;
>> class Whatever{}
>>
>> It's a one-line change to keep your code working. I think that's
> acceptable,
>
> It's not acceptable, as you're breaking BC.
>
>> For whatever the opinion of someone who writes PHP all day and not C
>> is worth, there it is.
>
> What makes you think I am different?
You write C at all and have commit access to CVS, and I do neither? (I wasn't
intending it as a snarky comment. I was acknowledging that I don't write code
for the engine and at present am not able to do so, as my C is far too rusty.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
As a developer and member of the community, the following is my two-cents on
the subject:
On Dec 4, 2007 5:16 PM, Derick Rethans <[EMAIL PROTECTED]> wrote:
> 1. As it is impossible to do "use XXX as NativeClass" we get to the
> point where we'd have to namespace new internal native classes
> otherwise we might introduce BC breaks
>
> Basically prefixing the classnames... This you can already do just
> fine without namespaces.
I agree. If the solution to this is to start adding prefixes to the aliased
names, then namespaces lose part of their purpose.
2. You have to import every class yourself. You can currently not do:
>
>use myNamespace::* as *; // or similar syntax
>
>
Globbing of this nature, in my humbled opinion, would not be the best idea
because of the high potential of problems. But, in the same respect, with
very large applications, it is much more preferable than to manually include
possibly hundreds of namespaces.
> 3. We keep bickering over using { } or not, multiple namespaces in a
> file or not... etc. I understand that people want more flexibility,
> but also we need a *simple* to explain implementation. With the
> current implementation I see the following problems here:
>
> - You can't stick multiple namespaces in one file
> - Unlike other constructs in PHP that mark executable blocks,
> namespaces don't use { }.
> - The "namespace" keyword at the start of a file is somewhat magic,
> because it can only appear as first element in your script.
I think this is a huge issue, if only for consistency with other constructs
of the language. There are already three different ways to write an
if/switch/while/for/etc condition: 1) With braces, 2) Without braces, and 3)
Alternate colon syntax (i.e., if ($blah == true):). Maybe namespaces should
conform to the existing conventions instead of introducing a new one that is
likely to just add yet another layer of confusion.
The same can be argued for the multiple-namspaces-per-file argument. If I
can put more than one class in a single file, then I should be able to put
more than one namespace in a file. Performance gains/losses aside, this is a
coding convention, and maintainability starts with consistency.
> 4. What is wrong with simple prefixes in the first place? Both PEAR_*,
> Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
> 'namespaces'. We could optionally create a registry on php.net for
> this to avoid conflicts.
>
The only difference, on the surface, that I see with namespaces vs. standard
prefixing is that namespaces has a new keyword and changes the separator
from an underscore to the double colon. Beyond that, without the other
features, namespaces doesn't sound very interesting as a feature of the
language, so as a developer I wouldn't feel compelled to use it in any
capacity.
> With all the above considerations, especially my first point, I still have
> not
> heard any good reason why namespaces in the current implementation are
> actually
> useful - or what particular case they solve... so I am wondering, are they
> really useful? I come now to the conclusion that they are not, and for
> myself
> (and most likely my work projects) I would have to decide not to go with
> namespaces, but instead stick with the 3 letter prefixing. Something that
> I
> have totally no problem with, as it is nice and easy.
>
For what it's worth, I would have to completely agree with Derick on this
issue. It just seems that namespaces could be made to do much more than it
already does.
--
It looked like something resembling white marble, which was
probably what it was: something resembling white marble.
-- Douglas Adams, "The Hitchhikers Guide to the Galaxy"
Re: [PHP-DEV] RFC: Dropping Namespace
Autoload would work exactly the same with namespaces, just do a str_replace and replace "::" with "_". On Wed, 2007-12-05 at 09:52 +0100, Robert Lemke wrote: > Hi Derick, > > I also agree with your arguments - beautifying class names is not > reason enough for > introducing namespaces. > > On 04.12.2007 at 23:16 Derick Rethans wrote: > > > 4. What is wrong with simple prefixes in the first place? Both PEAR_*, > > Zend_*, ezc*, and ezp* are perfectly acceptable markers for > > different > > 'namespaces'. We could optionally create a registry on php.net for > > this to avoid conflicts. > > > While experimenting with namespaces to use with the next major version > of > TYPO3, I realized that always using a full class name such as > > "T3_MyPackage_MySubPackage_Controller_DefaultController" > > has many advantages. Autoloading becomes a lot easier and if the > filename > equals the class name (ie. the full name, not only > "DefaultController.php") > you are never in doubt where a file belongs to or comes from. > > Therefore we in the TYPO3 project currently tend to not using namespaces > even if PHP6 had support for them. > > robert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
Hi Ronald, Am 05.12.2007 um 11:08 schrieb Ronald Chmara: http://www.phpbuilder.com/lists/php-documentation-list/ 2001071/0109.php I, for one, would not enjoy typing out: "T3_MyPackage_MySubPackage_Controller_DefaultController" any more often than I absolutely *had* to. well, in a way I agree - I don't like typing more than I need either. However, for me verbose naming of methods, variables and classes is a very important factor for readable (and maintainable) code - but that's probably yet another story. Especially in a framework context there a lot of options how you can make things more convenient, with convention over configuration for example. In the end it might turn out that a developer doesn't have to type class names that often anymore and the length of such a name gets less important. Finally, another important reason for us to not use namespaces is the lack of available refactoring tools. Imagine you want to rename a class "T3_Cool_Fancy_Stuff" to "T3_Cool_Fancy_Tool". A global search / replace and renaming the class file will usually do - if you use the full class name everywhere. However, just trying to search and replace "Stuff" will probably break your code. robert -- http://typo3.org/gimmefive http://buzz.typo3.org/people/robert-lemke/ PGP.sig Description: This is a digitally signed message part
Re: [PHP-DEV] RFC: Dropping Namespace
On Dec 5, 2007, at 12:52 AM, Robert Lemke wrote: Hi Derick, I also agree with your arguments - beautifying class names is not reason enough for introducing namespaces. On 04.12.2007 at 23:16 Derick Rethans wrote: 4. What is wrong with simple prefixes in the first place? Both PEAR_*, Zend_*, ezc*, and ezp* are perfectly acceptable markers for different 'namespaces'. We could optionally create a registry on php.net for this to avoid conflicts. While experimenting with namespaces to use with the next major version of TYPO3, I realized that always using a full class name such as "T3_MyPackage_MySubPackage_Controller_DefaultController" has many advantages. Autoloading becomes a lot easier and if the filename equals the class name (ie. the full name, not only "DefaultController.php") you are never in doubt where a file belongs to or comes from. Therefore we in the TYPO3 project currently tend to not using namespaces even if PHP6 had support for them. Wow, total Deja Vu. http://www.phpbuilder.com/lists/php-documentation-list/2001071/0109.php I, for one, would not enjoy typing out: "T3_MyPackage_MySubPackage_Controller_DefaultController" any more often than I absolutely *had* to. And in a somewhat amusing sense, the "register_global" vs. "local variable" debates aren't that far off from "register_class_as_global" vs. "local class namespace" debates Maybe we could all just re-read the email archives from back then, and save ourselves a lot of arguing? :) -Bop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
On Tue, 4 Dec 2007, Larry Garfield wrote:
> 1) "use MyDate as DateTime". I believe Greg pointed out the solution here.
> When PHP 5.5 is released and adds its own Whatever class, you just do the
> following:
>
> namespace me;
> use Whatever as LegacyWhatever;
> class Whatever{}
>
> It's a one-line change to keep your code working. I think that's acceptable,
It's not acceptable, as you're breaking BC.
> For whatever the opinion of someone who writes PHP all day and not C
> is worth, there it is.
What makes you think I am different?
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
On Tue, 4 Dec 2007, Stanislav Malyshev wrote:
> > following some discussions on the list (re. multiple namespaces in file) as
> > well as a short discussion on IRC regarding not being able to do
> > "use yeti::xml::DomDocument as DomDocument;" - I do not see any point in
> > having
>
> You mean like ability to override existing classes? I think it could be done
> but I don't see it as a good idea - it probably would lead to some weird
> programming mistakes.
Of course, I think allowwing this is a really bad idea - which brings me
to the main point of this argument:
> > > 1. As it is impossible to do "use XXX as NativeClass" we get to the
> > > point
> > where we'd have to namespace new internal native classes
> >otherwise we might introduce BC breaks. AFAIK, we've always said that
>
> There's very easy solution to this, if it ever becomes a problem - using
> two-component names.
And that is exactly what I think we should not do. PHP reserves the
global scope. period. That means that (core)extensions should not have
to deal with all sorts of namespace clue or other tricks just because
some people like a "misguided" implementation of namespaces. The idea of
namespaces is to prevent collisions in USER land code, not turning
internal PHP classes into a pile of goo.
> > 3. We keep bickering over using { } or not, multiple namespaces in a
> >file or not... etc. I understand that people want more flexibility,
> >but also we need a *simple* to explain implementation. With the
>
> That's why not all flexibility gets in.
>
> >- You can't stick multiple namespaces in one file
>
> You are not supposed to unless you using it as performance solution, which is
> rather dubious practice anyway.
You're not supposed to put a count($array) inside your for loop either.
I don't quite understand why allowing multiple namespaces is such a big
issue, however - it won't solve the naming collision issue.
> >- Unlike other constructs in PHP that mark executable blocks,
> > namespaces don't use { }.
>
> That's because namespaces are not executable blocks.
Neither are classes.
> > 4. What is wrong with simple prefixes in the first place? Both PEAR_*,
> >Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
> >'namespaces'. We could optionally create a registry on php.net for
> >this to avoid conflicts.
>
> What is wrong is names like
> PEAR_DB_Data_Database_Module_Adapter_Implementation_Interface_Exception_Information_Collection_Element.
> When you write a code that uses such names, you really don't want to repeat
> all the thing every time.
No, but, do you really need to have such long names? And besides that,
you *have* to keep repeating them in every file you'd want to use them -
which means you actually have to type *more* in some places. So this
argument is kind of lame.
> > useful - or what particular case they solve... so I am wondering, are they
> > really useful? I come now to the conclusion that they are not, and for
> > myself
>
> Yes, they are.
Just saying "Yes, they are" is not a very good argument - actually, it's
not an argument at all.
> > (and most likely my work projects) I would have to decide not to go with
> > namespaces, but instead stick with the 3 letter prefixing. Something that I
>
> Well, the loss is all yours :)
Actually, it's exactly the opposite, as I avoid naming colissions
(point 1), I don't need to import every class I want to use (point 2),
and can group all my classes together in one file (point 3).
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
Hi Derick, I also agree with your arguments - beautifying class names is not reason enough for introducing namespaces. On 04.12.2007 at 23:16 Derick Rethans wrote: 4. What is wrong with simple prefixes in the first place? Both PEAR_*, Zend_*, ezc*, and ezp* are perfectly acceptable markers for different 'namespaces'. We could optionally create a registry on php.net for this to avoid conflicts. While experimenting with namespaces to use with the next major version of TYPO3, I realized that always using a full class name such as "T3_MyPackage_MySubPackage_Controller_DefaultController" has many advantages. Autoloading becomes a lot easier and if the filename equals the class name (ie. the full name, not only "DefaultController.php") you are never in doubt where a file belongs to or comes from. Therefore we in the TYPO3 project currently tend to not using namespaces even if PHP6 had support for them. robert -- WE NEED UNICODE! http://typo3.org/gimmefive http://buzz.typo3.org/people/robert-lemke/ PGP.sig Description: This is a digitally signed message part
Re: [PHP-DEV] RFC: Dropping Namespace
On Dec 4, 2007 10:36 PM, Robert Cummings <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-12-04 at 22:26 -0600, Larry Garfield wrote:
> > On Tuesday 04 December 2007, Derick Rethans wrote:
> >
> > > 4. What is wrong with simple prefixes in the first place? Both PEAR_*,
> > >Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
> > >'namespaces'. We could optionally create a registry on php.net for
> > >this to avoid conflicts.
> >
> > Although most people on the list seem to be coming at this problem assuming
> > classes, I want to offer a counter-example that is all functions.
> >
> > In Drupal, our plugin architecture is based on function naming. When a
> > given
> > event "omg" occurs, something akin to the following frequently happens (a
> > bit
> > simplified):
> >
> > $hook = 'omg';
> > foreach ($modules_that_are_loaded as $module) {
> > $function = $module .'_'. $hook;
> > if (function_exists($function)) {
> > $return[] = $function();
> > }
> > }
> > return $return;
> >
> > It's a very powerful mechanism, and quite flexible. The one thing it
> > doesn't
> > offer is, given a function name, determine what module and hook/event it is
> > for. That's because we use PHP core coding standards, which say to use
> > function_name for all functions. So given this function name:
> >
> > views_do_stuff()
> >
> > Is that the "do stuff" hook from the "views" module/plugin, or the "stuff"
> > hook from the "views_do" module? Excellent question, and one that cannot be
> > reliably solved. (There is a module called "views", but nothing is stopping
> > anyone from writing a "views_do" module and declaring their own "stuff"
> > hook.)
>
>
> $hook = 'omg';
> foreach ($modules_that_are_loaded as $module)
> {
> $function = $module .'__'. $hook;
> if (function_exists($function))
> {
> $return[] = $function();
> }
> }
> return $return;
>
> ?>
>
> There ye have it!
>
>
> list( $module, $hook ) = explode( '__', $function );
>
> ?>
>
> Namespace support is for people who didn't name their classes/functions
> properly. I'm not for or against it.
To paint namespaces with such a broad brush isn't terribly fair. I
see other languages such as Java/Perl/C++ using packages/namespace foo
in much the same way I see some people wanting to use it here. As a
way to shorten really long class names while reducing conflicts.
This isn't a new feature to programming in general. The problem I see
going on here is the desire by some to make it do everything _and_
wash the dishes. While noble and probably well intentioned, does
feature X really serve the greater good? It can't solve every problem
and still be something that people want to use.
Php already has a ton of stuff in the global namespace, so I don't
know that namespaces can fix collisions/BC overnight. Once namespaces
have a foothold then people can start looking at how to migrate all
the stuff in the global namespace outwards without causing major
problems. While PHP::Time::DateSpan might seem silly to some, it
seems fairly normal in the other languages I program in (Java, Perl).
I would also be perfectly fine with php core laying claim to Time::*.
Its just a fact of life that the global namespace has a limited amout
of real estate and people can't just go snatching up all the good
names just because they were there first.
I vote for starting small. Add namespaces. Allow people to do basic
use statements. I would even be in favor of multiple namespaces per
file, but would prefer if they were wrapped in {} (it seems more
consistent and easier to mentally parse) otherwise I don't care. From
reading emails today I hope this might be some sort of middle ground
that might prevent completely tossing out this feature.
Having said all of that, you can't stop bad programmers from doing at
least something wrong. Especially not in a language like PHP where
you are given so much freedom to do what you want.
--
-Nathan Gordon
If the database server goes down and there is no code to hear it, does
it really go down?
:wq
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
Hi Larry,
namespace me;
use Whatever as LegacyWhatever;
class Whatever{}
I'd missed that in the ebb and flow. I guess the bug in my copy was fixed
then, good. It still doesn't make sense to have global import though...?
(I'm probably going to kick myself sooo hard for this in the morning...)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
I think namespaces are very useful when it comes to PHP in large scale applications with hundreds of functions/classes. On Tue, 2007-12-04 at 16:39 -0600, Brian Moon wrote: > > With all the above considerations, especially my first point, I still have > > not > > heard any good reason why namespaces in the current implementation are > > actually > > useful - or what particular case they solve... so I am wondering, are they > > really useful? I come now to the conclusion that they are not, and for > > myself > > (and most likely my work projects) I would have to decide not to go with > > namespaces, but instead stick with the 3 letter prefixing. Something that I > > have totally no problem with, as it is nice and easy. > > I hate to, but I agree. If the only point is to make class naming > pretty, it is kind of pointless. Give me namespaces that scope > variables to a file and then we have something. Yeah, I still code the > way PHP intended you to code, by templateing files together and not > making gynormous classes to print out some simple HTML over and over. > > It would only be useful in that my company's code would not conflict > with some 3rd party software we use. > > -- > > Brian Moon > Senior Developer > -- > http://dealnews.com/ > It's good to be cheap =) > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
On Tue, 2007-12-04 at 22:26 -0600, Larry Garfield wrote:
> On Tuesday 04 December 2007, Derick Rethans wrote:
>
> > 4. What is wrong with simple prefixes in the first place? Both PEAR_*,
> >Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
> >'namespaces'. We could optionally create a registry on php.net for
> >this to avoid conflicts.
>
> Although most people on the list seem to be coming at this problem assuming
> classes, I want to offer a counter-example that is all functions.
>
> In Drupal, our plugin architecture is based on function naming. When a given
> event "omg" occurs, something akin to the following frequently happens (a bit
> simplified):
>
> $hook = 'omg';
> foreach ($modules_that_are_loaded as $module) {
> $function = $module .'_'. $hook;
> if (function_exists($function)) {
> $return[] = $function();
> }
> }
> return $return;
>
> It's a very powerful mechanism, and quite flexible. The one thing it doesn't
> offer is, given a function name, determine what module and hook/event it is
> for. That's because we use PHP core coding standards, which say to use
> function_name for all functions. So given this function name:
>
> views_do_stuff()
>
> Is that the "do stuff" hook from the "views" module/plugin, or the "stuff"
> hook from the "views_do" module? Excellent question, and one that cannot be
> reliably solved. (There is a module called "views", but nothing is stopping
> anyone from writing a "views_do" module and declaring their own "stuff"
> hook.)
There ye have it!
Namespace support is for people who didn't name their classes/functions
properly. I'm not for or against it.
Cheers,
Rob.
--
...
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
On Tuesday 04 December 2007, Derick Rethans wrote:
> 4. What is wrong with simple prefixes in the first place? Both PEAR_*,
>Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
>'namespaces'. We could optionally create a registry on php.net for
>this to avoid conflicts.
Although most people on the list seem to be coming at this problem assuming
classes, I want to offer a counter-example that is all functions.
In Drupal, our plugin architecture is based on function naming. When a given
event "omg" occurs, something akin to the following frequently happens (a bit
simplified):
$hook = 'omg';
foreach ($modules_that_are_loaded as $module) {
$function = $module .'_'. $hook;
if (function_exists($function)) {
$return[] = $function();
}
}
return $return;
It's a very powerful mechanism, and quite flexible. The one thing it doesn't
offer is, given a function name, determine what module and hook/event it is
for. That's because we use PHP core coding standards, which say to use
function_name for all functions. So given this function name:
views_do_stuff()
Is that the "do stuff" hook from the "views" module/plugin, or the "stuff"
hook from the "views_do" module? Excellent question, and one that cannot be
reliably solved. (There is a module called "views", but nothing is stopping
anyone from writing a "views_do" module and declaring their own "stuff"
hook.)
That has actually come up recently as a problem, where we had to change the
way a feature was implemented in order to avoid that problem of lack of
introspection. (Ironically, it was when we were trying to implement lazy
loading of a larger number of files to *improve* performance by reducing the
amount of parsed-but-unused code we have.) We also are more and more coming
across very_long_function_names since the function name must begin with the
name of the module, which, if multi-word, can get quite long.
When I saw the namespaces implementation, I realized that was a good solution
to the problem. Instead of $module .'_'. $hook, use $module .'::'. $hook.
That doesn't use namespaces as an alias or a shortener, but as, genuinely, a
namespace.
That's what's wrong with Long_Name_Prefixes. Aside from being a bitch to type
or read, they don't contain as much introspective metadata as namespaces do.
A registry on php.net to avoid collisions solves the problem for only one
tiny sliver of use cases.
If the problem with the current namespace implementation is that it doesn't go
far enough, then the answer is not to drop it entirely but to finish it.
Even if it's not useful in every use case, there are a lot of use cases where
it is useful.
To the other items raised:
1) "use MyDate as DateTime". I believe Greg pointed out the solution here.
When PHP 5.5 is released and adds its own Whatever class, you just do the
following:
namespace me;
use Whatever as LegacyWhatever;
class Whatever{}
It's a one-line change to keep your code working. I think that's acceptable,
especially if we ensure that Whatever not existing in the global namespace
(on 5.4) doesn't cause an error. As Stanislav noted, a complete solution is
impossible. The Global namespace is a namespace, and you can't add things to
a namespace and expect there to never be a collision within that namespace.
Duh. :-)
2) No "use Foo::* as *". I can certainly see where that would be useful, but
the lack of it does not mean that the entire namespace implementation must be
thrown out. It still offers other benefits, even if it's not perfect (see
above), and I don't see where adding * capabilities in a later version would
cause a BC break syntactically, so worst case it's added later.
3) namespace keyword vs. {}. I've already said before that I prefer the {}
syntax for consistency with other constructs. I am less bothered by the
one-namespace-per-file rule than some, perhaps because I prefer to only parse
the code I need rather than loading everything. (In my common use case,
Drupal, that's a bigger performance win than vice versa.) I do agree that IF
multiple namespaces are allowed in one file, {} makes a lot more syntactic
sense than just a keyword. That said... is the keyword vs. {} issue worth
deep sixing namespaces completely? If so, um, let's switch to {} (with or
without multiple namespaces per file) and solve the problem? :-)
For whatever the opinion of someone who writes PHP all day and not C is worth,
there it is.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
--
P
Re: [PHP-DEV] RFC: Dropping Namespace
up a few days ago and again, everyone who says that they get a performance gain by aggregating the files (Like compiled PHP files) are being either ignored or in some way insulted... Anyways, some That's the first time I hear asking somebody to help reproducing his benchmark is an insult. But how it has anything to do with removing namespaces? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
following some discussions on the list (re. multiple namespaces in file)
as well as a short discussion on IRC regarding not being able to do
"use yeti::xml::DomDocument as DomDocument;" - I do not see any point in having
You mean like ability to override existing classes? I think it could be
done but I don't see it as a good idea - it probably would lead to some
weird programming mistakes.
1. As it is impossible to do "use XXX as NativeClass" we get to the
point where we'd have to namespace new internal native classes
otherwise we might introduce BC breaks. AFAIK, we've always said that
There's very easy solution to this, if it ever becomes a problem - using
two-component names.
2. You have to import every class yourself. You can currently not do:
use myNamespace::* as *; // or similar syntax
Right, you can't - but you can use two-component names, i.e.
myNamespace::Name.
3. We keep bickering over using { } or not, multiple namespaces in a
file or not... etc. I understand that people want more flexibility,
but also we need a *simple* to explain implementation. With the
That's why not all flexibility gets in.
- You can't stick multiple namespaces in one file
You are not supposed to unless you using it as performance solution,
which is rather dubious practice anyway.
- Unlike other constructs in PHP that mark executable blocks,
namespaces don't use { }.
That's because namespaces are not executable blocks.
- The "namespace" keyword at the start of a file is somewhat magic,
because it can only appear as first element in your script.
Yes, it is somewhat magic, because it changes how names behave. If the
whole thread is really reincarnation of the braces theme - I think you
could just link to the archive, as I don't see any arguments here that
weren't discussed to death three times.
4. What is wrong with simple prefixes in the first place? Both PEAR_*,
Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
'namespaces'. We could optionally create a registry on php.net for
this to avoid conflicts.
What is wrong is names like
PEAR_DB_Data_Database_Module_Adapter_Implementation_Interface_Exception_Information_Collection_Element.
When you write a code that uses such names, you really don't want to
repeat all the thing every time.
useful - or what particular case they solve... so I am wondering, are they
really useful? I come now to the conclusion that they are not, and for myself
Yes, they are.
(and most likely my work projects) I would have to decide not to go with
namespaces, but instead stick with the 3 letter prefixing. Something that I
Well, the loss is all yours :)
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
On Dec 4, 2007 5:41 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> Hi D,
>
> > extension (DateTime, DateTimeZone). However introducing the new class
> > DateTimeSpan might break people's code that do things like:
> >
> > > use myNamespace::DateTimeZone as DateTimeZone;
> > ?>
>
> Typo? I guess you meant 'DateTimeSpan' to be in there somewhere...
>
> This is I think the biggest problem with the implementation, that new
> internal classes can still break userland code. The problem of single-file
> namespacing is only a problem because of the performance implications for
> those who bundle their includes, and it _should_ be possible to find a good
> way to resolve that. I don't really see a problem with the 'use only at the
> head of the file' thing (although I know others do); in fact I prefer it,
> because it makes for an easier upgrade path.
>
> Can I just ask one thing? If namespace support is once again pulled before
> it sees the light of a release, can we _please_ document exactly what the
> problems were, loud and clear, and put the document somewhere people are
> likely to see it?
>
> Thanks,
>
> - Steph
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I never thought it would get back to the drawing board that way, but
Derick, as I said on irc when we discussed about that, I agree with
you. With the current implementation, the namespaces should be removed
completely. Not only because it has missing features, but from the
voice that comes out of the community, it seems that some features
(important ones) (Point 2) and some PHP general concept (Point 3) are
simply not what people want.
I do not want to start a flamewar here, but again, the { } thread came
up a few days ago and again, everyone who says that they get a
performance gain by aggregating the files (Like compiled PHP files)
are being either ignored or in some way insulted... Anyways, some
people do not believe in the aggregation of the files, why's that ? I
am not quite sure, well I have a few ideas but they are not
appropriate for the mailing list, but the optimization technique that
is aggregating the files work and I would really love to see it stay
(At least the ability to decide if I want to aggregate them or not).
And this is currently not possible with the implementation.
Things like use * as * is something that is missing and a very
important feature to my eyes as well. However, this kind of feature
comes with education. If we allow people to use * as *, we have to
explain them that the namespaces are not going to be coding for you.
They might introduce the same conflicting errors as before when they
had only classes. I want to make sure people understand that
namespaces are not there to make one type less but as a great man once
said, an additional structural element that is to be used correctly in
order to work correctly.
(You can give a nail to someone and he'll stick it in his eye instead
of building a house... but if you show him how to use the nail
correctly and with which other tools, he'll be able to build something
solid... maybe...)
>From what I have experienced since the namespaces are in, my prefixing
is still the way to go to make sure I can run all my nifty
optimization scripts around and make a few "free" optimizations.
This is a thread that will probably go deep in the sand in a few days
(unless the community arises (which doesn't usually happen)) but for
the records, if anyone has anything to say, it's still the time :)
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
Hi D, extension (DateTime, DateTimeZone). However introducing the new class DateTimeSpan might break people's code that do things like: Typo? I guess you meant 'DateTimeSpan' to be in there somewhere... This is I think the biggest problem with the implementation, that new internal classes can still break userland code. The problem of single-file namespacing is only a problem because of the performance implications for those who bundle their includes, and it _should_ be possible to find a good way to resolve that. I don't really see a problem with the 'use only at the head of the file' thing (although I know others do); in fact I prefer it, because it makes for an easier upgrade path. Can I just ask one thing? If namespace support is once again pulled before it sees the light of a release, can we _please_ document exactly what the problems were, loud and clear, and put the document somewhere people are likely to see it? Thanks, - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
With all the above considerations, especially my first point, I still have not heard any good reason why namespaces in the current implementation are actually useful - or what particular case they solve... so I am wondering, are they really useful? I come now to the conclusion that they are not, and for myself (and most likely my work projects) I would have to decide not to go with namespaces, but instead stick with the 3 letter prefixing. Something that I have totally no problem with, as it is nice and easy. I hate to, but I agree. If the only point is to make class naming pretty, it is kind of pointless. Give me namespaces that scope variables to a file and then we have something. Yeah, I still code the way PHP intended you to code, by templateing files together and not making gynormous classes to print out some simple HTML over and over. It would only be useful in that my company's code would not conflict with some 3rd party software we use. -- Brian Moon Senior Developer -- http://dealnews.com/ It's good to be cheap =) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Dropping Namespace
Hello,
following some discussions on the list (re. multiple namespaces in file)
as well as a short discussion on IRC regarding not being able to do
"use yeti::xml::DomDocument as DomDocument;" - I do not see any point in having
namespaces at all. And my excuses for the somewhat longish mail...
Some arguments:
1. As it is impossible to do "use XXX as NativeClass" we get to the
point where we'd have to namespace new internal native classes
otherwise we might introduce BC breaks. AFAIK, we've always said that
PHP reserves the globals space for it's own use (see also:
http://www.php.net/manual/en/userlandnaming.rules.php). In case we do
add new classes (an example could be DateTimeSpan), they should of
course follow the same format as already existing classes in the
extension (DateTime, DateTimeZone). However introducing the new class
DateTimeSpan might break people's code that do things like:
feature versions of people would then show:
Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument
because the name is already in use.
It would be silly to require to have to do this:
- Create a class PHP::Date::TimeSpan
- In your scripts:
use PHP::Date::TimeSpan
But with the current implementation, this seems to be the only non-BC
breaking solution. If we chose *not* to require this silly namespacing
of internal classes, users instead have to do this:
Basically prefixing the classnames... This you can already do just
fine without namespaces.
2. You have to import every class yourself. You can currently not do:
use myNamespace::* as *; // or similar syntax
I understand why this is not implemented (runtime vs. compile time),
but it is a bit of a pain in the ass if you use lots of classes from
your own library f.e.
3. We keep bickering over using { } or not, multiple namespaces in a
file or not... etc. I understand that people want more flexibility,
but also we need a *simple* to explain implementation. With the
current implementation I see the following problems here:
- You can't stick multiple namespaces in one file
- Unlike other constructs in PHP that mark executable blocks,
namespaces don't use { }.
- The "namespace" keyword at the start of a file is somewhat magic,
because it can only appear as first element in your script.
4. What is wrong with simple prefixes in the first place? Both PEAR_*,
Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
'namespaces'. We could optionally create a registry on php.net for
this to avoid conflicts.
With all the above considerations, especially my first point, I still have not
heard any good reason why namespaces in the current implementation are actually
useful - or what particular case they solve... so I am wondering, are they
really useful? I come now to the conclusion that they are not, and for myself
(and most likely my work projects) I would have to decide not to go with
namespaces, but instead stick with the 3 letter prefixing. Something that I
have totally no problem with, as it is nice and easy.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
