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.
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
add
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 Gr
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
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 clas
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"
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 impor
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
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 ide
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 p
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 capa
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
+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
+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 o
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
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 PROT
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 n
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
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 und
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 coatin
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::Contro
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
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
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
>> foll
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
>
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
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 ag
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_
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 on
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 l
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 marker
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* ar
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...
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 namespa
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 opt
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 conflic
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 h
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
d
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
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 clas
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, a
41 matches
Mail list logo