Re: [PHP-DEV] RFC: Dropping Namespace
Stanislav Malyshev
> 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
st...@zend.com http://www.zend.com/
(408)253-8829 MSN: st...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
> 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
> bug that is easily fixed. use should allow re-aliasing of global
> classes, and I could provide a very easy fix.
This is not a bug - since there you work with test::xmlreader, which of
course you can define. But in global space you'd work with existing name
xmlreader, which would be redefined. And PHP never allowed redefining
classes.
> file1.php:
> <?php
> class DB {}
> ?>
>
> file2.php:
> <?php
> import DB as Other_DB;
> include 'file1.php';
> class DB extends Other_DB {}
> ?>
You mean 'use' should kill the old name? I don't think it's a good idea
- we'd have to keep track of killed names, and since class can be named
in a lot of ways - i.e. if you have name A::B::C::D you can alias any
part of name, it would become messy.
Why exactly you need to rename existing classes?
Steph Fox
>> bug that is easily fixed. use should allow re-aliasing of global
>> classes, and I could provide a very easy fix.
>
> This is not a bug - since there you work with test::xmlreader, which of
> course you can define. But in global space you'd work with existing name
> xmlreader, which would be redefined. And PHP never allowed redefining
> classes.
I'm truly glad you said that's not a bug, my world just started to make
sense again. But Stas, consider (old dialect bc I need to update locally
sorry):
import nstest::test as whatever;
This works in the global space, right? Now along comes, say, Pierre or
Derick or Marcus with this class they just have to add to an existing
(non-namespaced) core extension, and the obvious and perfect name for this
class happens to be 'whatever'. I upgrade PHP and suddenly I start seeing
Fatal error: Import name 'whatever' conflicts with defined class in ...
Now sure, I can fix that. I can search and replace all my instances of
'whatever' in my code. How is that different from what we had before?
Greg would say I should've namespaced this file, I know... but it's possible
to use import (OK, 'use' now) in the global space, so how are you going to
prevent people from doing that?
- Steph
Stanislav Malyshev
> sorry):
>
> import nstest::test as whatever;
>
> This works in the global space, right? Now along comes, say, Pierre or
Right.
> Derick or Marcus with this class they just have to add to an existing
> (non-namespaced) core extension, and the obvious and perfect name for
> this class happens to be 'whatever'. I upgrade PHP and suddenly I start
> seeing
Right again. The thing is this problem can not be solved. You can not
both put all your classes into global namespace and expect them never to
clash even when you name two of them by the same name. That's like you
would talk in a language where all words would be "marklar" and expect
me to understand you :)
So what we can do is to avoid getting into such problem by using some
rules. I'd propose these rules:
1. Namespace your libraries
2. Do not import the class name into global space, but only library name.
Meaning, if your class is nstest::test, there's nothing wrong with
saying just so, if you are concerned about clashes. That's not worse
than you has nstest_test previously. But if you had PEAR::DB::Connection
and PEAR::DB::Connection::Data and PEAR::DB::Connection::Exception and
PEAR::DB::Query::Term and PEAR::DB::Query::Result, then you could do:
use PEAR::DB as myDB;
use PEAR::DB::Query as myQuery;
and you'd have to do much less work: just myQuery::Term and
myQuery::Result.
> Now sure, I can fix that. I can search and replace all my instances of
> 'whatever' in my code. How is that different from what we had before?
If you insist on putting everything into globals space - it won't be. We
just give you the option of not doing it.
> Greg would say I should've namespaced this file, I know... but it's
> possible to use import (OK, 'use' now) in the global space, so how are
> you going to prevent people from doing that?
I can't. I can only hope they would do it right, I can't force them to
do it right :)
--
Stanislav Malyshev, Zend Software Architect
st...@zend.com http://www.zend.com/
(408)253-8829 MSN: st...@zend.com
--
Steph Fox
> it right :)
I guess what I'm really asking is, 'is there any point in allowing
import/use to be used in the global space?' I'm tired and etc, but I just
can't visualize where it would be useful.
Maybe one of the OO gang could put me straight here?
- Steph
Steph Fox
> import/use to be used in the global space?' I'm tired and etc, but I just
> can't visualize where it would be useful.
And now I've finished reading old South Park episodes...
OK, it's sinking in now. Because global import/use is something you only
have to type once, whereas you'd have to add the namespace declaration, the
relevant includes and any specific imports from the global namespace on a
per-file basis (unless that last is a bug in my ageing PHP copy).
Sorry, I'm slower than the average glacier tonight :(
Even so... if you want your code to be safe from potential naming collisions
you'd need to do all that stuff _anyway_, so what's the point in having a
quick and dirty way to be unsafe? What am I missing here? Surely if people
don't want to utilize namespacing in their own code they should just stick
with fully qualified names?
I'm asking a lot of questions because I'd _like_ this to work, I just don't
see it as working if it's possible to break a namespaced application with
third-party changes. To me that's the main reason for having namespace
support in the first place, and without it, namespace support is just a way
to prettify names.
I'd like wildcard support too... and support for multiple namespaces per
file (for bundling only)... but neither of those are complete deal-breakers
in my eyes. Protection from naming collisions, is.
- Steph
Larry Garfield
> 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
la...@garfieldtech.com 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
Robert Cummings
<?php
$hook = 'omg';
foreach ($modules_that_are_loaded as $module)
{
$function = $module .'__'. $hook;
if (function_exists($function))
{
$return[] = $function();
}
}
return $return;
?>
There ye have it!
<?php
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.
Cheers,
Rob.
--
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
Sam Barrow
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 =)
Steph Fox
> 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
Nate Gordon
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?
<esc>:wq<CR>
Benjamin Schulz
On 05.12.2007, at 04:28, Steph Fox wrote:
> I'd like wildcard support too... and support for multiple namespaces
> per file (for bundling only)... but neither of those are complete
> deal-breakers in my eyes. Protection from naming collisions, is.
FULLACK, the good news is that i accidently mailed Gregory off-list
yesterday and he seems to have a good solution.
Derick Rethans
> However, in the global scope (no namespace) it would fail. This is a
> bug that is easily fixed. use should allow re-aliasing of global
> classes, and I could provide a very easy fix.
No, use should not allow this. Take the following example:
<?php
namespace blah;
use DomDocument as test;
class DOMDocument { }
$dom = new DOMDocument; //
$dom->loadXML('<books><book><title>blah</title></book></books>');
$s = simplexml_import_dom($dom);
echo $s->book[0]->title; // blah
?>
Besides this being a *big* WTF factor (why is my internal class
suddendly doing something else?) simplexml will horrible fail in this
case.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
Robert Lemke
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
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/
--Apple-Mail-20--505782854
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFHVmbRDu+3qCHvGSIRAq/hAKCnfGpXQrLCGur12rxD6IROvx74dQCfSIMb
3fF2NXvECxR6VUwhFjO2zxo=
=2AHJ
-----END PGP SIGNATURE-----
--Apple-Mail-20--505782854--
Derick Rethans
> > 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 Rethans
> 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?
Dmitry Stogov
Did you try to run it?
It produces error as expected.
DOMDocument() in your example is a user-space class that is not related
to internal ext/dom class. If you like to use internal class that is
overriden in namespace you can use ::DomDocument instead.
The "use DomDocument as test;" is useless from my point of view.
You always may override internal classes in namespaces.
Thanks. Dmitry.
Derick Rethans wrote:
> On Tue, 4 Dec 2007, Gregory Beaver wrote:
>
>> However, in the global scope (no namespace) it would fail. This is a
>> bug that is easily fixed. use should allow re-aliasing of global
>> classes, and I could provide a very easy fix.
>
> No, use should not allow this. Take the following example:
>
> <?php
> namespace blah;
> use DomDocument as test;
>
> class DOMDocument { }
>
> $dom = new DOMDocument; //
> $dom->loadXML('<books><book><title>blah</title></book></books>');
> $s = simplexml_import_dom($dom);
>
> echo $s->book[0]->title; // blah
> ?>
>
> Besides this being a *big* WTF factor (why is my internal class
> suddendly doing something else?) simplexml will horrible fail in this
> case.
>
> Derick
>
--
Marcus Boerger
Wednesday, December 5, 2007, 2:33:47 AM, you wrote:
>>> However, in the global scope (no namespace) it would fail. This is a
>>> bug that is easily fixed. use should allow re-aliasing of global
>>> classes, and I could provide a very easy fix.
>>
>> This is not a bug - since there you work with test::xmlreader, which of
>> course you can define. But in global space you'd work with existing name
>> xmlreader, which would be redefined. And PHP never allowed redefining
>> classes.
> I'm truly glad you said that's not a bug, my world just started to make
> sense again. But Stas, consider (old dialect bc I need to update locally
> sorry):
> import nstest::test as whatever;
> This works in the global space, right? Now along comes, say, Pierre or
> Derick or Marcus with this class they just have to add to an existing
> (non-namespaced) core extension, and the obvious and perfect name for this
> class happens to be 'whatever'. I upgrade PHP and suddenly I start seeing
> Fatal error: Import name 'whatever' conflicts with defined class in ...
There is no technical reason for this. If this is true I am strongly against
namespaces at all because then there is nothing usefull left.
Best regards,
Marcus
Ronald Chmara
> 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:
>
>> 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.
>
> 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
Robert Lemke
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
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/
--Apple-Mail-1--498793923
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFHVoIeDu+3qCHvGSIRAhGAAKDKx4TxrgkIUGTjO0+jvXWZT8Iq8QCffjpP
DsXxrVos/obO6Z4KH0UTebw=
=Syt3
-----END PGP SIGNATURE-----
--Apple-Mail-1--498793923--
Sam Barrow
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
Ken Stanley
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 <der...@php.net> 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"
------=_Part_1332_23795064.1196867122617--
Larry Garfield
On Wed, 5 Dec 2007 09:55:40 +0100 (CET), Derick Rethans <der...@php.net> 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
Stanislav Malyshev
> properly.
Here's a claim so weird I don't know how to parse it.
--
Stanislav Malyshev, Zend Software Architect
st...@zend.com http://www.zend.com/
(408)253-8829 MSN: st...@zend.com
--
Robert Lemke
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
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 {
}
?>
<?php
namespace T3::OtherPackage::Controller;
class Fancy extends Default {
}
?>
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.
--Apple-Mail-19--473982979
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFHVuMNDu+3qCHvGSIRApeVAJ9iHZ8igBTLWjMU8GBSE2VHt2cvHACdGhH7
14qc2vlhMdxcEiUxHhDKeSs=
=J8Aw
-----END PGP SIGNATURE-----
--Apple-Mail-19--473982979--
Robert Cummings
> > 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!
...........................................................
--
Stanislav Malyshev
> 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
st...@zend.com http://www.zend.com/
(408)253-8829 MSN: st...@zend.com
--
Robert Lemke
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.
--
Stanislav Malyshev
> 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
st...@zend.com http://www.zend.com/
(408)253-8829 MSN: st...@zend.com
--
Stanislav Malyshev
> implemented currently I'm not really excited about them either.
So you are proposing to improve them how?
Martin Alterisio
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
2007/12/5, Robert Cummings <rob...@interjinn.com>:
>
> 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.
------=_Part_2207_27118067.1196878108203--
Sebastian Bergmann
> Given that it was technically feasible, (future) core classes should
> be in namespaces as well.
Or
- Introduce namespaces in PHP 6
- Move all functions and classes that are now global into
(per-extension) namespace(s)
- Add a fallback mechanism that looks up mysqli_query() as query()
in the MySQLi extension's namespace for PHP 6.0, drop that BC
layer in PHP 6.1
Not saying that I would want this (I don't think I do), just mentioning
the option.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Jochem Maas
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.
<remark type="OT" class="irrelevant">
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.
</remark>
>
>> 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).
Sam Barrow
be removed later.
::php
::str
::arr
::ob
etc
::ext
::mysql
::mysqli
Userland code can then use a namespace such as ::app, or just use the
global namespace with no worries. Probably not going to happen, atleast
not for a while, due to compatibility issues, but just a thought.
On Wed, 2007-12-05 at 17:43 +0100, Sebastian Bergmann wrote:
> Matthias Pigulla schrieb:
> > Given that it was technically feasible, (future) core classes should
> > be in namespaces as well.
>
> Or
>
> - Introduce namespaces in PHP 6
> - Move all functions and classes that are now global into
> (per-extension) namespace(s)
> - Add a fallback mechanism that looks up mysqli_query() as query()
> in the MySQLi extension's namespace for PHP 6.0, drop that BC
> layer in PHP 6.1
>
> Not saying that I would want this (I don't think I do), just mentioning
> the option.
>
> --
> Sebastian Bergmann http://sebastian-bergmann.de/
> GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
>
--
Benjamin Schulz
On 05.12.2007, at 17:43, Sebastian Bergmann wrote:
> Matthias Pigulla schrieb:
>> Given that it was technically feasible, (future) core classes should
>> be in namespaces as well.
>
> Or
>
> - Introduce namespaces in PHP 6
> - Move all functions and classes that are now global into
> (per-extension) namespace(s)
> - Add a fallback mechanism that looks up mysqli_query() as query()
> in the MySQLi extension's namespace for PHP 6.0, drop that BC
> layer in PHP 6.1
>
What about adding namespaced aliases for internal classes as a start
(basically: class spl::FileInfo extends SplFileInfo) and drop the old
names (SplFileInfo) in PHP6 and keep only the new ones.
David Zülke
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 =20
>>> idea
>>> of namespaces is to prevent collisions in USER land code, not =20
>>> turning
>>> internal PHP classes into a pile of goo.
>>
>> Yes, idea of namespaces is not to turn PHP classes into a pile of =20
>> 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 =20
>> namespaces" -
>> multiple namespaces per file? I object to allowing it for reasons =20
>> having
>> absolutely nothing to do with naming collisions, as anybody =20
>> bothering to
>> actually read what I wrote would immediately know.
>
> this implies that your objections to multiple namespaces per file is =20=
> valid
> whereas objections to the limitation are invalid.
>
> apparently people keep 'flogging this horse to death' because they =20
> are not
> convinced by your wisdom with regard to this decision - they may be =20=
> 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 =20
> blocks" doesn't
> hold up unless your willing to state the inconsistency is one of =20
> your design goals.
>
>>
>>> No, but, do you really need to have such long names? And besides =20
>>> 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.
>
> <remark type=3D"OT" class=3D"irrelevant">
> developers will complain, it's in their blood, nothing anyone will =20
> ever produce
> will change that ... somewhere in the future when all code is =20
> created without the
> intervention of man .. even then there will still be a compiler =20
> complaining.
> </remark>
>
>>
>>> you *have* to keep repeating them in every file you'd want to use =20=
>>> 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 - =20
>>> actually, it's
>>> not an argument at all.
>>
>> No more and no less than "I wonder if they are useful, let's just =20
>> delete
>> them".
>
> actually that is not true - a halfbaked concept is pretty much =20
> garanteed to give you
> and the users of your product more headaches than no implementation =20=
> at all. and
> once the genie is out of the bottle your stuck with it - with all =20
> 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 =20
> nothing namespaces would
> give us [in it's current form] that we cannot achieve already ... =20
> with the bonus that
> users are currently not restricted in the way they organize/rollout =20=
> 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 =20=
>>> 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 =20
>> 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 =20
> developer will be confronted
> with any problems they might bring with them, at some stage, because =20=
> there will be third
> party code out there that uses namespaces (code which for the sake =20
> of argument one would
> be required to use under some circumstances).
>
>>
>
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
David Z=FClke
d...@bitxtender.com
Tel: +49 (0)89 57 08 15 15
bitXtender GbR
Paul-Heyse-Stra=DFe 6
80336 M=FCnchen
Nate Gordon
> > collision problems that class naming and function naming have. Only
>
> 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?
<esc>:wq<CR>
Robert Cummings
>
> > namespaces bring to the table beyond that, is the ability to
> > shorthand the class names within the namespace... as I said candy
> > coating.
>
> 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!
...........................................................
--
Stanislav Malyshev
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
st...@zend.com http://www.zend.com/
(408)253-8829 MSN: st...@zend.com
--
Sam Barrow
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.
--
Steph Fox
>> 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
Gergely Hodicska
> 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ő
Derick Rethans
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:
>
> <?php
> 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:
>
> <?php
> 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
Dmitry Stogov
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 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.
--
Gregory Beaver
I am not sure this will make it through the noise *sigh* but I'll give a
try :)
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:
<?php
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 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 conflicts with internal classes are
never possible when "use"ing them
it becomes possible to change which class is used in a file with 1 line
of code:
<?php
use myNamespace::Exception as Exception;
?>
As opposed to two:
<?php
namespace __user__;
use myNamespace::Exception as Exception;
?>
Cons:
It is then possible to accidentally override an internal classname used
in the code.
it encourages continuing to declare classes/functions in the global
namespace, resulting in potential name conflicts a la "Date"
Gregory Beaver
message - I was trying to Ctrl-V to paste)
> =====================
4) keep things the way they work now, and recommend using "namespace
__user__" for userspace code.
Pros:
explicit declaration of namespace can make code clearer
Cons:
users using global namespace and "use" will get burned.
=========
As a reality check, in the entire lifetime of PHP, there has been only 1
name collision between new PHP classes and pre-existing major
classnames. SplFileInfo was originally a conflict, but that was solved
with a simple prefix to the classname of "Spl." This is an issue, but
until PHP starts adding billions of classes to handle core elements, it
is not a large one. However, it can be easily and simply solved, so I
say why not :).
After enumerating the pros/cons of each point, my personal opinion is
that #1 and #2 are not feasible from either a user or a core developer
standpoint, and would create more problems than they would solve. #3,
however, looks much more appealing than I thought it would. I think
this is a good idea as an addition. I might be inclined to ask for an
E_STRICT warning that "use My::Exception;" is overriding an internal
class, but that's up to what you all think. Implementing #3 would
remove the con of #4.
To answer Derick's call for clarification on #4, The convention of using
the __user__ namespace for all code that uses namespaced code would
force users to do two things:
1) explicitly "use" classnames they wish to shorten by importing them
from another namespace
2) add "namespace __user__" to the top of their files.
These two things would mean
1) autoload always works as intended
2) classes from external projects (dependencies not found in the current
file) are always documented prominently at the top of the file,
increasing maintainability if the project passes on to another developer.
3) the presence of "namespace __user__" would also immediately document
the fact that this code is intended to be executed and is not library
code (does not declare classes/functions and only uses them)
Point #1 does not matter to people who don't use autoload, but #2 and #3
both increase the ease of understanding the purpose of code. I've often
had trouble sifting through source code to find the main files that are
executed. If I could have done a simple "grep -e namespace __user__" it
would make things a lot easier that way.
Thanks,
Greg
Jessie Hernandez
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
<?php
namespace Zend;
class Exception extends ::Exception
{
// ...
};
?>
test1.php
<?php
use Zend::Exception;
throw new Exception( 'Zend exception occurred' );
?>
test2.php
<?php
use Zend::Exception as ZendException;
if( $someCondition )
throw new ZendException( 'Zend exception occurred' );
else
throw new Exception( 'unknown generic exception' );
?>
Regards,
Jessie