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?
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
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.
?php
namespace Foo;
use myNamespace::Bar as stdClass;
?
I think it is clear decision.
If you like to override internal classes just
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
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
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
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
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
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_*,
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 04.12.2007
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
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
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
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
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
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
+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.
+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
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
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
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
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:
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
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
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
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
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
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
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
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):
?php
namespace T3::MyPackage::Controller;
class Special extends Default {
}
?
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...
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,
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:
?php
use myNamespace::DateTimeZone as DateTimeZone;
?
Typo? I guess you meant
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
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
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
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.
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
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
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
41 matches
Mail list logo
