Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Question about Namespace patch »

Question about Namespace patch

php.internals

Markus Fischer

19 years ago
Hi, I've a few questions about the namespace patch: 1) Why is "import Foo" a no-op? Shouldn't it import everything define inside Foo? 2) How can I import all classes from a namespace at once? Like question 1) actually. "import Foo::*" doesn't work. 3) Shouldn't there be an error when importing a class which already existing in the current scope? Example ---------------8<-------------------- ns2.php: <?php namespace Foo; class Bar { public function __construct() { echo "Namespace class\n"; } } ns1.php: <?php require_once 'ns2.php'; class Bar { public function __construct() { echo "No namespace class\n"; } } import Foo::Bar; new Bar; C:\...\Desktop\php6>php ns1.php Namespace class ---------------8<-------------------- I read the thread an I know that I can still call access the global class with ::Bar ... but is this a intuitive behaviour? thanks, - Markus

Stanislav Malyshev

19 years ago
> 1) Why is "import Foo" a no-op? > Shouldn't it import everything define inside Foo?
No, it shouldn't.
> 2) How can I import all classes from a namespace at once?
Use namespace::class.
> 3) Shouldn't there be an error when importing a class which already > existing in the current scope? Example
I think there should be.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Derick Rethans

19 years ago
On Sun, 22 Jul 2007, Stanislav Malyshev wrote:
> > 2) How can I import all classes from a namespace at once? > > Use namespace::class.
That's not the answer to the question. Markus was asking how to import *all* classes from a namespace at *once*. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Jeremy Privett

19 years ago
And that's exactly why this implementation isn't intuitive. As far as I can see from the way it's been explained, so far, that is not possible. Jeremy -----Original Message----- From: Derick Rethans [mailto:derick@php.net] Sent: Monday, July 23, 2007 12:55 AM To: Stanislav Malyshev Cc: Markus Fischer; internals Subject: Re: [PHP-DEV] Question about Namespace patch On Sun, 22 Jul 2007, Stanislav Malyshev wrote:
> > 2) How can I import all classes from a namespace at once? > > Use namespace::class.
That's not the answer to the question. Markus was asking how to import *all* classes from a namespace at *once*. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Stanislav Malyshev

19 years ago
> And that's exactly why this implementation isn't intuitive. As far as I > can see from the way it's been explained, so far, that is not possible.
No implementation is "intuitive", unless by "intuitive" you mean "works as in that other language I know". Too bad in each of these languages it works differently :)
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Jeremy Privett

19 years ago
Stanislav, Absolutely not the case. Take a look at C++, C#, even Python. The "namespaces" implementation of those languages is mostly consistent (even if Python doesn't call it that). You're not helping developers at all with this implementation. If you're working with a large library and have to import a lot of classes, the way this works is nothing but a pain. We would be better off not using namespaces at all, in this case. Thus, the problem has not been solved. Also, for the implementation to be complete, Core Developers and Extension Developers would need to namespace their classes / functions. And that, undoubtedly, is a LOT of work. I can understand this being the justification for implementing namespaces in the way it's been implemented, because all of this other stuff in the global namespace, but you still need to offer developers *some* way of importing everything out of a namespace. I absolutely will have upwards to close to 25 - 30 classes in a single namespace. And sometimes more. To be able to import them all is an absolute necessity for this implementation to be remotely feasible. Having an import block at the top of files that's that huge just doesn't make any sense. And that doesn't even consider the fact that I may be using OTHER libraries as well that may be namespaced. PEAR is a perfect example of this. Look at all the libraries that exist there. I would absolutely love to just: import PEAR; import PEAR::HTTP; import PEAR::Image; And not have to worry about going through and picking out every little individual class that I need. And with all of the languages I mentioned before, that is *exactly* how it works. Of course, we're back to the namespacing of the PHP Core and Extensions. Which is really the main blocker to any serious namespaces implementation, beyond what's currently patched to HEAD today, correct? I hope you can better see my viewpoint, now that I actually had the time to sit down and type out a more coherent reply. This implementation and the unicode.semantics discussion have to be the most frustrating points PHP6 has for me, right now. Thanks. --- Jeremy Privett Software Developer Peak8 Solutions -----Original Message----- From: Stanislav Malyshev [mailto:stas@zend.com] Sent: Monday, July 23, 2007 1:39 AM To: Jeremy Privett Cc: Derick Rethans; Markus Fischer; internals Subject: Re: [PHP-DEV] Question about Namespace patch
> And that's exactly why this implementation isn't intuitive. As far as
I
> can see from the way it's been explained, so far, that is not
possible. No implementation is "intuitive", unless by "intuitive" you mean "works as in that other language I know". Too bad in each of these languages it works differently :)
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Alexey Zakhlestin

19 years ago
In reality, it is rarely (almost never) needed to import all the classes. Usually you need 2–4 per file, not more, and importing just what you really need is the step to a clean design. You don't need to import every class which is used implicitly, only those which are explicitly used. On 7/23/07, Jeremy Privett <jeremy@peak8solutions.com> wrote: > Stanislav, > > Absolutely not the case. Take a look at C++, C#, even Python. The > "namespaces" implementation of those languages is mostly consistent > (even if Python doesn't call it that). > > You're not helping developers at all with this implementation. If you're > working with a large library and have to import a lot of classes, the > way this works is nothing but a pain. We would be better off not using > namespaces at all, in this case. Thus, the problem has not been solved. > > Also, for the implementation to be complete, Core Developers and > Extension Developers would need to namespace their classes / functions. > And that, undoubtedly, is a LOT of work. I can understand this being the > justification for implementing namespaces in the way it's been > implemented, because all of this other stuff in the global namespace, > but you still need to offer developers *some* way of importing > everything out of a namespace. I absolutely will have upwards to close > to 25 - 30 classes in a single namespace. And sometimes more. To be able > to import them all is an absolute necessity for this implementation to > be remotely feasible. Having an import block at the top of files that's > that huge just doesn't make any sense. And that doesn't even consider > the fact that I may be using OTHER libraries as well that may be > namespaced. > > PEAR is a perfect example of this. Look at all the libraries that exist > there. I would absolutely love to just: > > import PEAR; > import PEAR::HTTP; > import PEAR::Image; > > And not have to worry about going through and picking out every little > individual class that I need. And with all of the languages I mentioned > before, that is *exactly* how it works. Of course, we're back to the > namespacing of the PHP Core and Extensions. Which is really the main > blocker to any serious namespaces implementation, beyond what's > currently patched to HEAD today, correct? > > I hope you can better see my viewpoint, now that I actually had the time > to sit down and type out a more coherent reply. This implementation and > the unicode.semantics discussion have to be the most frustrating points > PHP6 has for me, right now. > > Thanks. > > --- > Jeremy Privett > Software Developer > Peak8 Solutions > > -----Original Message----- > From: Stanislav Malyshev [mailto:stas@zend.com] > Sent: Monday, July 23, 2007 1:39 AM > To: Jeremy Privett > Cc: Derick Rethans; Markus Fischer; internals > Subject: Re: [PHP-DEV] Question about Namespace patch > > > And that's exactly why this implementation isn't intuitive. As far as > I > > can see from the way it's been explained, so far, that is not > possible. > > No implementation is "intuitive", unless by "intuitive" you mean "works > as in that other language I know". Too bad in each of these languages it > > works differently :) > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Jeremy Privett

19 years ago
Alexey, I honestly wish that were the case with the situation I'm dealing with at my current job. And I know a lot of people that are absolutely in the same boat as I am. I definitely understand your reasoning here, but we're obviously talking about design versus convenience. This is one of those situations where convenience makes the difference. Was there ever a decision on whether or not the patch is going to be backported to PHP5? I think I'll grab a PHP6 snapshot and toy around with the implementation a bit. Who knows ... it may grow on me. We'll see. Thanks. --- Jeremy Privett Software Developer Peak8 Solutions -----Original Message----- From: Alexey Zakhlestin [mailto:indeyets@gmail.com] Sent: Monday, July 23, 2007 2:14 AM To: Jeremy Privett Cc: Stanislav Malyshev; Derick Rethans; Markus Fischer; internals Subject: Re: [PHP-DEV] Question about Namespace patch In reality, it is rarely (almost never) needed to import all the classes. Usually you need 2-4 per file, not more, and importing just what you really need is the step to a clean design. You don't need to import every class which is used implicitly, only those which are explicitly used. On 7/23/07, Jeremy Privett <jeremy@peak8solutions.com> wrote:
> Stanislav, > > Absolutely not the case. Take a look at C++, C#, even Python. The > "namespaces" implementation of those languages is mostly consistent > (even if Python doesn't call it that). > > You're not helping developers at all with this implementation. If
you're
> working with a large library and have to import a lot of classes, the > way this works is nothing but a pain. We would be better off not using > namespaces at all, in this case. Thus, the problem has not been
solved.
> > Also, for the implementation to be complete, Core Developers and > Extension Developers would need to namespace their classes /
functions.
> And that, undoubtedly, is a LOT of work. I can understand this being
the
> justification for implementing namespaces in the way it's been > implemented, because all of this other stuff in the global namespace, > but you still need to offer developers *some* way of importing > everything out of a namespace. I absolutely will have upwards to close > to 25 - 30 classes in a single namespace. And sometimes more. To be
able
> to import them all is an absolute necessity for this implementation to > be remotely feasible. Having an import block at the top of files
that's
> that huge just doesn't make any sense. And that doesn't even consider > the fact that I may be using OTHER libraries as well that may be > namespaced. > > PEAR is a perfect example of this. Look at all the libraries that
exist
> there. I would absolutely love to just: > > import PEAR; > import PEAR::HTTP; > import PEAR::Image; > > And not have to worry about going through and picking out every little > individual class that I need. And with all of the languages I
mentioned
> before, that is *exactly* how it works. Of course, we're back to the > namespacing of the PHP Core and Extensions. Which is really the main > blocker to any serious namespaces implementation, beyond what's > currently patched to HEAD today, correct? > > I hope you can better see my viewpoint, now that I actually had the
time
> to sit down and type out a more coherent reply. This implementation
and
> the unicode.semantics discussion have to be the most frustrating
points
> PHP6 has for me, right now. > > Thanks. > > --- > Jeremy Privett > Software Developer > Peak8 Solutions > > -----Original Message----- > From: Stanislav Malyshev [mailto:stas@zend.com] > Sent: Monday, July 23, 2007 1:39 AM > To: Jeremy Privett > Cc: Derick Rethans; Markus Fischer; internals > Subject: Re: [PHP-DEV] Question about Namespace patch > > > And that's exactly why this implementation isn't intuitive. As far
as
> I > > can see from the way it's been explained, so far, that is not > possible. > > No implementation is "intuitive", unless by "intuitive" you mean
"works
> as in that other language I know". Too bad in each of these languages
it
> > works differently :) > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Richard Lynch

19 years ago
On Mon, July 23, 2007 3:13 am, Alexey Zakhlestin wrote:
> In reality, it is rarely (almost never) needed to import all the > classes. Usually you need 2–4 per file, not more, and importing just > what you really need is the step to a clean design. > > You don't need to import every class which is used implicitly, only > those which are explicitly used.
I've run into "enough" cases in several languages/projects over the years where I end up using damn near every class/function in a moderate-sized library. And you'd certainly want to do that if you're, say, writing some kind of higher-level glue-wrapper API sort of thing -- which is a not uncommon use-case. While it may not meet the 90% rule, it's super-painful for that 10% for any decent-sized library :-(
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?

Stanislav Malyshev

19 years ago
> Absolutely not the case. Take a look at C++, C#, even Python. The > "namespaces" implementation of those languages is mostly consistent > (even if Python doesn't call it that).
Come on, python modules are not like C++ namespaces at all. For starters, AFAIK, python doesn't even have namespace declaration operator. And module loading and namespacing are combined.
> You're not helping developers at all with this implementation. If you're
How many developers did you ask, honestly? I had asked some, and they say it helps. Including on the list. You wanted to say I'm not helping some other developers? Well, too bad, there's no patch that can solve everybody's problems :)
> working with a large library and have to import a lot of classes, the > way this works is nothing but a pain. We would be better off not using > namespaces at all, in this case. Thus, the problem has not been solved.
Once more, you DO NOT have to import a lot of classes. Please do read what I write. You SHOULD NOT import classes in global space. Namespaces are NOT the way to bring all classes in global space, and it should not be done.
> Also, for the implementation to be complete, Core Developers and > Extension Developers would need to namespace their classes / functions.
Not necessarily. So far PHP core & PECL has been OK without it, there's not too many classes and the names are quite manageable, unless I miss something.
> but you still need to offer developers *some* way of importing > everything out of a namespace. I absolutely will have upwards to close
No, I don't need that.
> to 25 - 30 classes in a single namespace. And sometimes more. To be able > to import them all is an absolute necessity for this implementation to
No, it is not an absolute necessity, actually it's exactly the opposite. You don't want each module to inject 30 new names into global space, because you'll be running out of names very, very fast.
> the fact that I may be using OTHER libraries as well that may be > namespaced. > > PEAR is a perfect example of this. Look at all the libraries that exist > there. I would absolutely love to just: > > import PEAR; > import PEAR::HTTP; > import PEAR::Image;
Yeah, and not since you have generic PEAR exception class, HTTP exception class and image exception class, you've got three exception classes competing with system exception class for the name. Lovely. So now we get PEAR::PEAR_Exception to prevent that, right? So how it's better than just PEAR::Exception?
> individual class that I need. And with all of the languages I mentioned > before, that is *exactly* how it works. Of course, we're back to the
No, actually it doesn't. In python import - and that's what most use - doesn't bring names into global space.
> namespacing of the PHP Core and Extensions. Which is really the main > blocker to any serious namespaces implementation, beyond what's > currently patched to HEAD today, correct?
No, incorrect. The main blocker was that all other implementations were either inconsistent, hurting performance or too complex for PHP.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Paweł Stradomski

19 years ago
Stanislav Malyshev wrote:
> > working with a large library and have to import a lot of classes, the > > way this works is nothing but a pain. We would be better off not using > > namespaces at all, in this case. Thus, the problem has not been solved. > > Once more, you DO NOT have to import a lot of classes. Please do read > what I write. You SHOULD NOT import classes in global space. Namespaces > are NOT the way to bring all classes in global space, and it should not > be done.
OK, so suppose I want to have four namespaces for my project: MyApp for some shared code, MyApp::Model MyApp::Controller MyApp::View Now in many places in my code in Model I'd use some ORM library - let's assume it's similar to python's SQLAlchemy. Now is there any way for me to have access **in Model namespace** to all classes from SQLAlchemy namespace without using import SQLAlchemy::Column import SQLAlchemy::Table import SQLAlchemy::Join import SQLAlchemy::ForeignKey import SQLAlchemy::Session import SQLAlchemy::Transaction and tens of other classes? I know your patch makes it possible to use fully qualified names everywhere.
-- Paweł Stradomski

Brian Moon

19 years ago
> import SQLAlchemy::Column > import SQLAlchemy::Table > import SQLAlchemy::Join > import SQLAlchemy::ForeignKey > import SQLAlchemy::Session > import SQLAlchemy::Transaction
Why use namespaces if you are going to do this? You are just bringing your classes into the global name space. The nice thing about namespaces IMO, is that I don't have to have a class named SQLAlchemy_Transaction. I can just have a class named Transaction in the SQLAlchemy namespace. I can then create a new object using $obj = new SQLAlchemy::Transaction.
-- Brian Moon Senior Developer ------------------------------ http://dealnews.com/ It's good to be cheap =)

David Zülke

19 years ago
Am 23.07.2007 um 16:25 schrieb Brian Moon:
>> import SQLAlchemy::Column >> import SQLAlchemy::Table >> import SQLAlchemy::Join >> import SQLAlchemy::ForeignKey >> import SQLAlchemy::Session >> import SQLAlchemy::Transaction > > Why use namespaces if you are going to do this? You are just > bringing your classes into the global name space. The nice thing > about namespaces IMO, is that I don't have to have a class named > SQLAlchemy_Transaction. I can just have a class named Transaction > in the SQLAlchemy namespace. I can then create a new object using > $obj = new SQLAlchemy::Transaction.
Oh yes, sure, that must be the main point about namespaces - I can use "::" instead of "_" as a delimiter! Yay! Come on, you can't be serious. David

Paweł Stradomski

19 years ago
Brian Moon wrote
> > import SQLAlchemy::Column > > import SQLAlchemy::Table > > import SQLAlchemy::Join > > import SQLAlchemy::ForeignKey > > import SQLAlchemy::Session > > import SQLAlchemy::Transaction > > Why use namespaces if you are going to do this? You are just bringing > your classes into the global name space. The nice thing about > namespaces IMO, is that I don't have to have a class named > SQLAlchemy_Transaction. I can just have a class named Transaction in > the SQLAlchemy namespace. I can then create a new object using $obj = > new SQLAlchemy::Transaction.
Because I just want those names directly available in one part of my application - the one which uses a lot of SQL. As far as I see this is not possibl with the proposed implementation - I can't do a local (file-scope or namespace-scope) import. All other languages I know that have namespaces (Java, python, C++) allow programmers to import other namespaces locally - usually for a single file.
-- Paweł Stradomski

Stanislav Malyshev

19 years ago
>>> 2) How can I import all classes from a namespace at once? >> Use namespace::class. > > That's not the answer to the question. Markus was asking how to import > *all* classes from a namespace at *once*.
That IS the answer. You don't. You use namespace::class instead. The whole purpose was to get them OUT of the global space, no reason to bring them back in.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Richard Lynch

19 years ago
On Mon, July 23, 2007 2:37 am, Stanislav Malyshev wrote:
>>>> 2) How can I import all classes from a namespace at once? >>> Use namespace::class. >> >> That's not the answer to the question. Markus was asking how to >> import >> *all* classes from a namespace at *once*. > > That IS the answer. You don't. You use namespace::class instead. The > whole purpose was to get them OUT of the global space, no reason to > bring them back in.
I have to say that often I'd just as soon suck the whole library in if it's a small enough project and I'm only using 1 library. I don't really want to type FullyQualifiedLibname:: a zillion times... I personally am not a zealot about getting things out of global namespace -- I just want the dang libraries to be able to not conflict when I used two and they both decided to call something 'Date'. :-) I'll then want to pull in the whole library that I use the "most" and use a fully-qualified name for the one I use the "least" Maybe that's just me, but I suspect it's actually pretty common.
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?