Question about Namespace patch

18 years ago by Markus Fischer — view source — reply

unread

Hi,

I've a few questions about the namespace patch:

Why is "import Foo" a no-op?
Shouldn't it import everything define inside Foo?
How can I import all classes from a namespace at once?
Like question 1) actually. "import Foo::*" doesn't work.
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

18 years ago by Stanislav Malyshev — view source — reply

unread

Why is "import Foo" a no-op?
Shouldn't it import everything define inside Foo?

No, it shouldn't.

How can I import all classes from a namespace at once?

Use namespace::class.

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

18 years ago by Derick Rethans — view source — reply

unread

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

18 years ago by Jeremy Privett — view source — reply

unread

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

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

18 years ago by Stanislav Malyshev — view source — reply

unread

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

18 years ago by Jeremy Privett — view source — reply

unread

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

18 years ago by Alexey Zakhlestin — view source — reply

unread

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.

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
http://blog.milkfarmsoft.com/

18 years ago by Jeremy Privett — view source — reply

unread

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.

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
http://blog.milkfarmsoft.com/

18 years ago by Richard Lynch — view source — reply

unread

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?

18 years ago by Stanislav Malyshev — view source — reply

unread

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

18 years ago by pstradomski@gmail.com — view source — reply

unread

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

18 years ago by Brian Moon — view source — reply

unread

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 =)

18 years ago by dz@bitxtender.com — view source — reply

unread

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

18 years ago by Derick Rethans — view source — reply

unread

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!

You forgot that you can also move the "prefix" in front of the class
name to "namespace prefix!"

Come on, you can't be serious.

I sort of agree, I don't see how the current implementation is really
useful for anything.

regards,
Derick

Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

18 years ago by Brian Moon — view source — reply

unread

Derick Rethans wrote:

I sort of agree, I don't see how the current implementation is really
useful for anything.

Well, for us, it would be useful for using 3rd party applications with
our internally written code. We have mostly a functional (as in C not
as in BASIC) environment. Recently we wanted to use Wordpress and
MediaWiki for an internal project. We had to drudge through THEIR code
and the error logs to find all the functions that conflicted with ones
in our own code library.

Now, if we had this namespaces implementation, we could namespace all of
our internal code with a namespace of dealnews and ideally those
projects would namespace their projects. This way there would be no
conflicts in the global scope.

Now, in Phorum, we did it the hard way and have hundreds of phorum_*
functions. It makes for some really bad reading code with those huge
function names.

I guess what this comes down to is that these namespaces are better for
project wide things and not so good at smaller parts. I agree that I
would not want to work with 50 different namespaces with this solution.
But, I would never work with 50 different namespaces as I don't find
that type of organization useful.

--

Brian Moon
Senior Developer

http://dealnews.com/
It's good to be cheap =)

18 years ago by nicobn@php.net — view source — reply

unread

Despite all the comments made on this list by countless people, it's still
Stanislav's way or the highway. I don't want to sound negative but come
on... this is getting ridiculous. Stanislav, why don't you just tell
everybody that you'll stop answering because the patch will stay AS IT IS
over your dead body anyway ? I think you'll save us all some time.

This discussion is endless and not productive. I can't speak for anybody
here but I think a vote by all people who have commit access to php-src
would clarify this issue once and for all so we can just move along.

But that's just my 2 cents.

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!

You forgot that you can also move the "prefix" in front of the class
name to "namespace prefix!"

Come on, you can't be serious.

I sort of agree, I don't see how the current implementation is really
useful for anything.

regards,
Derick

Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

--

--
Nicolas Bérard-Nault (nicobn@gmail.com)
Étudiant D.E.C. Sciences, Lettres & Arts
Cégep de Sherbrooke

Homepage: http://nicobn.googlepages.com

18 years ago by Jeremy Privett — view source — reply

unread

Yes, because that's ABSOLUTELY the way to respond to the community that has continued to support PHP. If that is what this discussion is going to degrade to, you're essentially saying "Please, gives us feedback but we're not listening."

If this is the case, then I'll keep in mind and make sure it's known that bringing your issues and feedback to the PHP Devs is such a lovely waste of time and energy.

Thanks.

Jeremy Privett
Software Developer
Peak8 Solutions

-----Original Message-----
From: nicobn@gmail.com [mailto:nicobn@gmail.com] On Behalf Of Nicolas Bérard-Nault
Sent: Monday, July 23, 2007 10:03 AM
To: Derick Rethans
Cc: David Zülke; PHP Internals
Subject: Re: [PHP-DEV] Question about Namespace patch

Despite all the comments made on this list by countless people, it's still
Stanislav's way or the highway. I don't want to sound negative but come
on... this is getting ridiculous. Stanislav, why don't you just tell
everybody that you'll stop answering because the patch will stay AS IT IS
over your dead body anyway ? I think you'll save us all some time.

This discussion is endless and not productive. I can't speak for anybody
here but I think a vote by all people who have commit access to php-src
would clarify this issue once and for all so we can just move along.

But that's just my 2 cents.

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!

You forgot that you can also move the "prefix" in front of the class
name to "namespace prefix!"

Come on, you can't be serious.

I sort of agree, I don't see how the current implementation is really
useful for anything.

regards,
Derick

Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

--

--
Nicolas Bérard-Nault (nicobn@gmail.com)
Étudiant D.E.C. Sciences, Lettres & Arts
Cégep de Sherbrooke

Homepage: http://nicobn.googlepages.com

18 years ago by David Coallier — view source — reply

unread

Yes, because that's ABSOLUTELY the way to respond to the community that has continued to support PHP. If that is what this discussion is going to degrade to, you're essentially saying "Please, gives us feedback but we're not listening."

If this is the case, then I'll keep in mind and make sure it's known that bringing your issues and feedback to the PHP Devs is such a lovely waste of time and energy.

Thanks.

Jeremy Privett
Software Developer
Peak8 Solutions

-----Original Message-----
From: nicobn@gmail.com [mailto:nicobn@gmail.com] On Behalf Of Nicolas Bérard-Nault
Sent: Monday, July 23, 2007 10:03 AM
To: Derick Rethans
Cc: David Zülke; PHP Internals
Subject: Re: [PHP-DEV] Question about Namespace patch

Despite all the comments made on this list by countless people, it's still
Stanislav's way or the highway. I don't want to sound negative but come
on... this is getting ridiculous. Stanislav, why don't you just tell
everybody that you'll stop answering because the patch will stay AS IT IS
over your dead body anyway ? I think you'll save us all some time.

This discussion is endless and not productive. I can't speak for anybody
here but I think a vote by all people who have commit access to php-src
would clarify this issue once and for all so we can just move along.

But that's just my 2 cents.

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!

You forgot that you can also move the "prefix" in front of the class
name to "namespace prefix!"

Come on, you can't be serious.

I sort of agree, I don't see how the current implementation is really
useful for anything.

regards,
Derick

Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

--

--
Nicolas Bérard-Nault (nicobn@gmail.com)
Étudiant D.E.C. Sciences, Lettres & Arts
Cégep de Sherbrooke

Homepage: http://nicobn.googlepages.com

--

Plus ca change, plus c'est pareil.

--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18

18 years ago by Stanislav Malyshev — view source — reply

unread

Yes, because that's ABSOLUTELY the way to respond to the community
that has continued to support PHP. If that is what this discussion is
going to degrade to, you're essentially saying "Please, gives us
feedback but we're not listening."

I responded - with arguments, explanation or reference to prior
arguments - to every comment on the list. It is hardly "not listening".
Maybe "not agreeing" - but nobody promised you to agree with everything
you say here. It's not what "feedback" means. It means you will be
listened to, your proposals would be weighted, discusses and seriously
considered. That is what you are getting. I can not promise you
immediate acceptance - and nobody would.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Jeremy Privett — view source — reply

unread

I wasn't referring to that. I know you've been responding to feedback. I was referring to Nicolas' suggested reply.

Jeremy Privett
Software Developer
Peak8 Solutions

-----Original Message-----
From: Stanislav Malyshev [mailto:stas@zend.com]
Sent: Monday, July 23, 2007 10:43 AM
To: Jeremy Privett
Cc: Nicolas Bérard-Nault; Derick Rethans; David Zülke; PHP Internals
Subject: Re: [PHP-DEV] Question about Namespace patch

Yes, because that's ABSOLUTELY the way to respond to the community
that has continued to support PHP. If that is what this discussion is
going to degrade to, you're essentially saying "Please, gives us
feedback but we're not listening."

I responded - with arguments, explanation or reference to prior
arguments - to every comment on the list. It is hardly "not listening".
Maybe "not agreeing" - but nobody promised you to agree with everything
you say here. It's not what "feedback" means. It means you will be
listened to, your proposals would be weighted, discusses and seriously
considered. That is what you are getting. I can not promise you
immediate acceptance - and nobody would.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Stanislav Malyshev — view source — reply

unread

Despite all the comments made on this list by countless people, it's still
Stanislav's way or the highway. I don't want to sound negative but come

No it isn't. If you failed to make convincing argument on one particular
case, it in no way means that I am deaf to any argument at all - it just
means your particular argument didn't convince me as of yet.

on... this is getting ridiculous. Stanislav, why don't you just tell
everybody that you'll stop answering because the patch will stay AS IT IS
over your dead body anyway ? I think you'll save us all some time.

Because it's not true. We consulted with many people before this
proposal, and we got positive feedbacks from yet more people after we
made this proposal. Of course, there are people that have different
opinion. But there's a difference between discussing opinions and
dismissing other's opinion as illogical brain-dead stubbornness. I think
I took a lot of effort in explaining my position - in many cases much
more than opposing side did, when some people pretty much summed up with
"your proposal is crap, it's not like Java, so I have no use for it". I
will continue to put an effort in explaining. I however would not change
my position just because somebody feels sore when his argument turns out
not be as persuasive as he thought it would be.

This discussion is endless and not productive. I can't speak for anybody

Make it productive. Propose something productive. By that I mean a
consistent concept that will be superior to existing one. Or at least a
consistent amendment to existing concept that would improve it.

here but I think a vote by all people who have commit access to php-src
would clarify this issue once and for all so we can just move along.

I don't think these issues have to be decided by arithmetics. Of course,
writing "+1" is much easier than spending a month on researching
possible solution, considering all implications of each one and figuring
out the optimal one - but I don't see any value in the former unless the
latter was done. That doesn't mean expressing an opinion is to be
discouraged - but there's more than sum of +1-es to make an informed
decision that is going to influence PHP for years to come. I welcome
everybody to make a contribution and discuss things - but please do not
assume if you have an opinion everybody would agree.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by nicobn@php.net — view source — reply

unread

I agree with some (if not most) of your positions on namespaces and I do
think the work you've put on this issue is valuable. However, I just fail to
see who, other than people with karma on php-src (and that excludes me)
could decide what the implementation will be in the end.

In the end, I think you're right though, some people will not like it and
some will. That's how painful life is. Sorry if I was too harsh on you.

Despite all the comments made on this list by countless people, it's
still
Stanislav's way or the highway. I don't want to sound negative but come

No it isn't. If you failed to make convincing argument on one particular
case, it in no way means that I am deaf to any argument at all - it just
means your particular argument didn't convince me as of yet.

on... this is getting ridiculous. Stanislav, why don't you just tell
everybody that you'll stop answering because the patch will stay AS IT
IS
over your dead body anyway ? I think you'll save us all some time.

Because it's not true. We consulted with many people before this
proposal, and we got positive feedbacks from yet more people after we
made this proposal. Of course, there are people that have different
opinion. But there's a difference between discussing opinions and
dismissing other's opinion as illogical brain-dead stubbornness. I think
I took a lot of effort in explaining my position - in many cases much
more than opposing side did, when some people pretty much summed up with
"your proposal is crap, it's not like Java, so I have no use for it". I
will continue to put an effort in explaining. I however would not change
my position just because somebody feels sore when his argument turns out
not be as persuasive as he thought it would be.

This discussion is endless and not productive. I can't speak for anybody

Make it productive. Propose something productive. By that I mean a
consistent concept that will be superior to existing one. Or at least a
consistent amendment to existing concept that would improve it.

here but I think a vote by all people who have commit access to php-src
would clarify this issue once and for all so we can just move along.

I don't think these issues have to be decided by arithmetics. Of course,
writing "+1" is much easier than spending a month on researching
possible solution, considering all implications of each one and figuring
out the optimal one - but I don't see any value in the former unless the
latter was done. That doesn't mean expressing an opinion is to be
discouraged - but there's more than sum of +1-es to make an informed
decision that is going to influence PHP for years to come. I welcome
everybody to make a contribution and discuss things - but please do not
assume if you have an opinion everybody would agree.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

--
Nicolas Bérard-Nault (nicobn@gmail.com)
Étudiant D.E.C. Sciences, Lettres & Arts
Cégep de Sherbrooke

Homepage: http://nicobn.googlepages.com

18 years ago by Stanislav Malyshev — view source — reply

unread

I agree with some (if not most) of your positions on namespaces and I do
think the work you've put on this issue is valuable. However, I just
fail to see who, other than people with karma on php-src (and that
excludes me) could decide what the implementation will be in the end.

I agree, but I don't agree that sum of votes is a good way to reach a
good decision in this case.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Derick Rethans — view source — reply

unread

Despite all the comments made on this list by countless people, it's still
Stanislav's way or the highway. I don't want to sound negative but come
on... this is getting ridiculous. Stanislav, why don't you just tell
everybody that you'll stop answering because the patch will stay AS IT IS
over your dead body anyway ? I think you'll save us all some time.

There is no need to start attacking people so directly. Please keep it
civilized.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

18 years ago by pstradomski@gmail.com — view source — reply

unread

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

18 years ago by Stanislav Malyshev — view source — reply

unread

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

If you want names to be part of global space - don't use namespaces.
Namespaces are meant to take names OUT of global space.

All other languages I know that have namespaces (Java, python, C++) allow
programmers to import other namespaces locally - usually for a single file.

Both Java and Python have much more rigid relations to files than PHP
does - in Java, class is file, more or less, and package is directory,
while in Python module is file and package is directory. Also, Java is a
compiled language - meaning you have much more information in compile
time than with PHP - all classes you use are to be known compile-time.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by pstradomski@gmail.com — view source — reply

unread

Stanislav Malyshev wrote:

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

If you want names to be part of global space - don't use namespaces.
Namespaces are meant to take names OUT of global space.

Once again. I do not want classes/function from ORM lib to clutter my global
namespace everywhere. I just want everything from it to be available in
couple of files (where lots of SQL/mapping) is going to be used. In those few
files I'll be able to keep control of names and avoid conflicts.
Sure, I can prefix all the names or insert a bunch of imports, although it'll
just be ugly.

And about "not using namespaces" - there are such things as code libraries.
Those will probalby be namespaced - so I'll be using namespaces even in small
scripts - just because I'll be using those libs.

If using a bunch of imports is the only way that is accepted - then at least a
shortcut like python's "from x import a,b,c,d,e,f,g,h" would be a nice.

--
Paweł Stradomski

18 years ago by Stanislav Malyshev — view source — reply

unread

Once again. I do not want classes/function from ORM lib to clutter my global
namespace everywhere. I just want everything from it to be available in
couple of files (where lots of SQL/mapping) is going to be used. In those few
files I'll be able to keep control of names and avoid conflicts.
Sure, I can prefix all the names or insert a bunch of imports, although it'll
just be ugly.

Maybe if you use a really hairy ORM with a real lot of levels with real
lot of namespaces on each level which you all need it might be a bit
ugly. It's the same in other languages too - Java and Python code is no
stranger to a bunch of imports at the start of the file. And BTW if you
have such library structure blanket imports won't help you either since
you'd have to do a bunch of imports to capture all the levels.

If using a bunch of imports is the only way that is accepted - then at least a
shortcut like python's "from x import a,b,c,d,e,f,g,h" would be a nice.

Supporting comma syntax to group imports is probably a good idea, should
hurt anything. As for supporting "from X import A, B, C" - I guess this
is to mean "import X::A, X::B, X::C" - we need to think about it.
Anyway, there's always an option of just using X::A, X::B and X::C -
remember, putting things in global space is not a requirement, prefix is
OK. What is not OK is a overly long prefix.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Andy Mason — view source — reply

unread

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

If you want names to be part of global space - don't use namespaces.
Namespaces are meant to take names OUT of global space.

All other languages I know that have namespaces (Java, python, C++) allow
programmers to import other namespaces locally - usually for a single
file.

Both Java and Python have much more rigid relations to files than PHP
does - in Java, class is file, more or less, and package is directory,

Is this something that you would consider for PHP ?
As far as I can tell from the list the two main considerations are not
pushing the decision to the executor and it being simple.

Would this not satisfy all of the above. At compile time you could
import everything and still know where it came from because ultimately
you have the namespace from the location of the file.

Its pretty easy to explain, you did it in one line, and it would solve
other peoples issues with namespaces without polluting the global
namespace.

The only downside is that this now requires a 1 class / file. This
IMHO isn't a massive problem as long as it can be explained, and those
who have the task of splitting this up now can do an import Foo::*; ?

thoughts?

Andrew

while in Python module is file and package is directory. Also, Java is a
compiled language - meaning you have much more information in compile
time than with PHP - all classes you use are to be known compile-time.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Stanislav Malyshev — view source — reply

unread

Is this something that you would consider for PHP ?
As far as I can tell from the list the two main considerations are not
pushing the decision to the executor and it being simple.

I can consider it as much as I want - and applications like Zend
Framework do work this way - but I also know not everybody works this
way. In fact, I get requests right here for having all code of whole
library handled as single file...

The only downside is that this now requires a 1 class / file. This
IMHO isn't a massive problem as long as it can be explained, and those
who have the task of splitting this up now can do an import Foo::*; ?

I don't see any imports involving * happening, since they all have a
common problem - you don't know what you are importing. Fortunately,
they also are completely unnecessary - if you need all things inside
Foo, why won't you just refer to them as Foo::things?

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Andy Mason — view source — reply

unread

Well i'm not in favour of the importing of everything , i don't see
the need for it personally but others do, as you well know. I was just
trying to find a way to achieve everyone goals without sacrificing
speed or correctness for those who want it =)

Shame about the single file thing though. I'm out of ideas, so best of luck :)
Andrew

Is this something that you would consider for PHP ?
As far as I can tell from the list the two main considerations are not
pushing the decision to the executor and it being simple.

I can consider it as much as I want - and applications like Zend
Framework do work this way - but I also know not everybody works this
way. In fact, I get requests right here for having all code of whole
library handled as single file...

The only downside is that this now requires a 1 class / file. This
IMHO isn't a massive problem as long as it can be explained, and those
who have the task of splitting this up now can do an import Foo::*; ?

I don't see any imports involving * happening, since they all have a
common problem - you don't know what you are importing. Fortunately,
they also are completely unnecessary - if you need all things inside
Foo, why won't you just refer to them as Foo::things?

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Stanislav Malyshev — view source — reply

unread

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

18 years ago by Richard Lynch — view source — reply

unread

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?

18 years ago by Giedrius D — view source — reply

unread

David Zülke wrote:

Oh yes, sure, that must be the main point about namespaces - I can use
"::" instead of "_" as a delimiter! Yay!

If all you are going to do is:

<?php

include "MyClass.php";
import MyClass;

?>

Then why use a namespace? I really don't see the point. Namespaces are
doing nothing for you in this case.

It is not always in your power to decide if you need namespace or not.
If you use
some lib from Vendor1 there's a good chance that all lib is in Vendor1 namespace
you want it or not.

If you use that Vendor1 lib in one.php file a lot you clutter your code with
Vendor1::A, Vendor1::B, Vendor1::C, etc. It is possible to rename Vendor1
to something shorter using import but you still have to prefix it.

Now as import has effect only in file where it was used it would be nice to
import all names from Vendor1 to the file one.php where it is heavy used and
not to the ones that include one.php.

So if the second.php file includes one.php global namespace is not
cluttered with
names from Vendor1 namespace. Only with names from one.php (if its names are
not in some namespace by them selves.) This way second.php may include&import
some lib from Vendor2 to accomplish its tasks without even worrying about libs
used in one.php.

That's why people sometimes want to import all names from namespace.

Regards,
Giedrius

18 years ago by Stanislav Malyshev — view source — reply

unread

If you use that Vendor1 lib in one.php file a lot you clutter your code
with
Vendor1::A, Vendor1::B, Vendor1::C, etc. It is possible to rename Vendor1
to something shorter using import but you still have to prefix it.

I see no problem with Vendor1::A, it's not overly long. When you have
Vendor1::A::B::C::D::E then it's long, but you can shorten that. Of
course, if you use many different sets with very narrow cross-section it
may mean you'd have still to use long names or have a bunch of imports,
but putting everything into global space in no way would solve the
problem - as I mentioned, good names run out pretty fast, and blanket
import means you can never use a plain English word to name any class in
your application - because there's a high probability that somebody else
would use the same word and thus your library becomes incompatible with
his once both are imported. That is on top of a myriad of technical
problems that blanket imports bring (think complete impossibility of
compile-time name resolution and the trouble of maintaining separate
per-file global scopes).
Also, having a bunch of imports is not that bad if you use a tool - like
an IDE - to assist with it.

That's why people sometimes want to import all names from namespace.

I understand why they may want this, but implementing such
functionalities opens a very large can of very nasty worms - since
libraries start being import-incompatible and then people start making
names like Vendor1_Module_Submodule_Exception all over again just to
allow their library to be imported with other library.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Andrew Minerd — view source — reply

unread

On Mon, 23 Jul 2007 10:02:43 -0700
stas@zend.com (Stanislav Malyshev) wrote:

I understand why they may want this, but implementing such
functionalities opens a very large can of very nasty worms - since
libraries start being import-incompatible and then people start making
names like Vendor1_Module_Submodule_Exception all over again just to
allow their library to be imported with other library.

Once again, you're trying to solve an application problem in the language. It will be the application importing the library, thus is it is up to the application to solve conflicts (i.e., not import everything from both namespaces). Currently, an application can't do anything about name conflicts in libraries short of editing the source; namespaces (assuming the libraries adopt them) give the application that power. That's where the language's responsibility ends.

If there are technical reasons (i.e., compile-time name resolution, as you mentioned in passing), I think it'd be beneficial to see a discussion of those.

A programming language is a tool: a hammer doesn't tell you where to put the nail.

--
Andrew Minerd
Software Architect
The Selling Source, Inc.

If you use that Vendor1 lib in one.php file a lot you clutter your code
with
Vendor1::A, Vendor1::B, Vendor1::C, etc. It is possible to rename Vendor1
to something shorter using import but you still have to prefix it.

I see no problem with Vendor1::A, it's not overly long. When you have
Vendor1::A::B::C::D::E then it's long, but you can shorten that. Of
course, if you use many different sets with very narrow cross-section it
may mean you'd have still to use long names or have a bunch of imports,
but putting everything into global space in no way would solve the
problem - as I mentioned, good names run out pretty fast, and blanket
import means you can never use a plain English word to name any class in
your application - because there's a high probability that somebody else
would use the same word and thus your library becomes incompatible with
his once both are imported. That is on top of a myriad of technical
problems that blanket imports bring (think complete impossibility of
compile-time name resolution and the trouble of maintaining separate
per-file global scopes).
Also, having a bunch of imports is not that bad if you use a tool - like
an IDE - to assist with it.

That's why people sometimes want to import all names from namespace.

I understand why they may want this, but implementing such
functionalities opens a very large can of very nasty worms - since
libraries start being import-incompatible and then people start making
names like Vendor1_Module_Submodule_Exception all over again just to
allow their library to be imported with other library.

18 years ago by Stanislav Malyshev — view source — reply

unread

it is up to the application to solve conflicts (i.e., not import
everything from both namespaces). Currently, an application can't do

Exactly - not import everything from namespaces. That's what we are doing :)

anything about name conflicts in libraries short of editing the
source; namespaces (assuming the libraries adopt them) give the

Actually, they can and they do - they use long names which have high
chance to be unique. This works, but this is extremely ugly and
inconvenient to work with.

If there are technical reasons (i.e., compile-time name resolution,
as you mentioned in passing), I think it'd be beneficial to see a
discussion of those.

Compile-time resolution means you don't get performance penalty for
namespaces when you are not using it, and have very low costs when you
do use it. Allowing blanket imports means we don't know what "new Foo()"
means until it is executed - meaning we need to make extra lookups on
each class fetch, even if the code doesn't use namespaces at all. That's
only one problem with blanket imports.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Andrew Minerd — view source — reply

unread

On Mon, 23 Jul 2007 11:08:58 -0700
stas@zend.com (Stanislav Malyshev) wrote:

Exactly - not import everything from namespaces. That's what we are doing :)

Well, first of all, not exactly. I think you meant: not import everything from two or more namespaces with conflicting names. Secondly, that's not the only solution. You could import everything from one, and not import from the other (or use a shorter prefix). Thirdly, you're not preventing collisions at all:

import Zend::DB;
import My::DB;
import Woot::Database as DB;

And what of applications that use libraries without any conflicting names? Let's just be honest about what you're saying: this patch is intentionally crippled.

Actually, they can and they do - they use long names which have high
chance to be unique. This works, but this is extremely ugly and
inconvenient to work with.

The application does? No: the library does. Currently, an application that is using two libraries with conflicting names can do nothing to resolve the conflicts. With namespace imports (barring a namespace collision), the application chooses how it's going to reference the names within a given library.

Allowing blanket imports means we don't know what "new Foo()"
means until it is executed

No: that comes from applying imports at run-time. A "blanket" import could only be applied to classes available at compile time. Granted, that'd be somewhat confusing, but, at the very least, address the proper issue.

That's only one problem with blanket imports.

So..... What are the others?

Andrew Minerd
Software Architect
The Selling Source, Inc.

18 years ago by Markus Fischer — view source — reply

unread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andrew,

Andrew Minerd wrote:

Well, first of all, not exactly. I think you meant: not import everything from two or more namespaces with conflicting names. Secondly, that's not the only solution. You could import everything from one, and not import from the other (or use a shorter prefix). Thirdly, you're not preventing collisions at all:

import Zend::DB;
import My::DB;
import Woot::Database as DB;

I don't quite understand your example. When I look at it in real life, I
would go for:

import Zend::DB as ZBD;
import My::DB as MDB;
import Woot::Database as DB;

I mean, that's is the point, to have more readable code == shorter
identifiers, isn't it?

So your code continues to read (just made up):

$oZdb = ZDB::factor('mysql');
$oMdb = MDB::getInstance('oracle');
$oWdb = DB::getDriver('postgres');

instead of:

$oZdb = Zend::DB:factor...
$oMdb = My::DB::getInstance
$oWdb = Woot::Database::getDriver..

Isn't that a win, at last?

That's how I understood. Maybe I got that wrong.

- Markus
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.6 (MingW32)
  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpPYT1nS0RcInK9ARAmQmAKDGsYj/ZY0FNojQobKb3bK2NL6QDgCcDKgl
LnyIP65ymnx180f7/WD5WfM=
=LjpG
-----END PGP SIGNATURE

18 years ago by dz@bitxtender.com — view source — reply

unread

That's exactly how import w/ aliasing is supposed to be used, you got
that perfectly right.

David

Am 23.07.2007 um 20:40 schrieb Markus Fischer:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andrew,

Andrew Minerd wrote:

Well, first of all, not exactly. I think you meant: not import
everything from two or more namespaces with conflicting names.
Secondly, that's not the only solution. You could import
everything from one, and not import from the other (or use a
shorter prefix). Thirdly, you're not preventing collisions at all:

import Zend::DB;
import My::DB;
import Woot::Database as DB;

I don't quite understand your example. When I look at it in real
life, I
would go for:

import Zend::DB as ZBD;
import My::DB as MDB;
import Woot::Database as DB;

I mean, that's is the point, to have more readable code == shorter
identifiers, isn't it?

So your code continues to read (just made up):

$oZdb = ZDB::factor('mysql');
$oMdb = MDB::getInstance('oracle');
$oWdb = DB::getDriver('postgres');

instead of:

$oZdb = Zend::DB:factor...
$oMdb = My::DB::getInstance
$oWdb = Woot::Database::getDriver..

Isn't that a win, at last?

That's how I understood. Maybe I got that wrong.

Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpPYT1nS0RcInK9ARAmQmAKDGsYj/ZY0FNojQobKb3bK2NL6QDgCcDKgl
LnyIP65ymnx180f7/WD5WfM=
=LjpG
-----END PGP SIGNATURE

18 years ago by Larry Garfield — view source — reply

unread

I'm fine with single-import-with-alias, from the descriptions here.
Effectively, then, there is no concept of "import". There is just an alias,
and mass-operation aliasing is quite messy.

I am more curious how far it goes in the supporting utilities. I saw that
there is a NAMESPACE constant, which is nice. Is there also a way to get
the "full name" of a function or class, so you can see where it came from?
Does import work for functions as well as classes?

Where I can see a huge use for namespaces is plugin-based architectures. Each
plugin is its own namespace. If you have a list of plugins, then you have a
list of namespaces and can iterate over that and invoke the same operation on
each plugin. That would require call_user_func() and call_user_func_array()
and the rest of that family to be able to handle namespaces. How would one
do that? Vis, is the callback type[1] namespace aware, or does it not have
to be?

(If this is already documented somewhere, please let me know where.)

[1]
http://us.php.net/manual/en/language.pseudo-types.php#language.types.callback

That's exactly how import w/ aliasing is supposed to be used, you got
that perfectly right.

David

Am 23.07.2007 um 20:40 schrieb Markus Fischer:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andrew,

Andrew Minerd wrote:

Well, first of all, not exactly. I think you meant: not import
everything from two or more namespaces with conflicting names.
Secondly, that's not the only solution. You could import
everything from one, and not import from the other (or use a
shorter prefix). Thirdly, you're not preventing collisions at all:

import Zend::DB;
import My::DB;
import Woot::Database as DB;

I don't quite understand your example. When I look at it in real
life, I
would go for:

import Zend::DB as ZBD;
import My::DB as MDB;
import Woot::Database as DB;

I mean, that's is the point, to have more readable code == shorter
identifiers, isn't it?

So your code continues to read (just made up):

$oZdb = ZDB::factor('mysql');
$oMdb = MDB::getInstance('oracle');
$oWdb = DB::getDriver('postgres');

instead of:

$oZdb = Zend::DB:factor...
$oMdb = My::DB::getInstance
$oWdb = Woot::Database::getDriver..

Isn't that a win, at last?

That's how I understood. Maybe I got that wrong.

Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpPYT1nS0RcInK9ARAmQmAKDGsYj/ZY0FNojQobKb3bK2NL6QDgCcDKgl
LnyIP65ymnx180f7/WD5WfM=
=LjpG
-----END PGP SIGNATURE-----

--

--
Larry Garfield AIM: LOLG42
larry@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

18 years ago by Stanislav Malyshev — view source — reply

unread

Where I can see a huge use for namespaces is plugin-based architectures. Each
plugin is its own namespace. If you have a list of plugins, then you have a
list of namespaces and can iterate over that and invoke the same operation on
each plugin. That would require call_user_func() and call_user_func_array()
and the rest of that family to be able to handle namespaces. How would one

Since namespace is just a part of class name, I don't see any problem
for call_user_func() to be able to use namespaced names. Of course, they
should get full class name - if you want to use shorter ones you'd have
to change something. Here we might need some functionality, but it's not
clear to me yet which one.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Andrew Minerd — view source — reply

unread

On Tue, 24 Jul 2007 11:53:38 -0700
stas@zend.com (Stanislav Malyshev) wrote:

Where I can see a huge use for namespaces is plugin-based architectures. Each
plugin is its own namespace. If you have a list of plugins, then you have a
list of namespaces and can iterate over that and invoke the same operation on
each plugin. That would require call_user_func() and call_user_func_array()
and the rest of that family to be able to handle namespaces. How would one

Since namespace is just a part of class name, I don't see any problem
for call_user_func() to be able to use namespaced names. Of course, they
should get full class name - if you want to use shorter ones you'd have
to change something. Here we might need some functionality, but it's not
clear to me yet which one.

w/ snapshot from yesterday:

andrewm@ds38 /usr/local/src/php6.0-200707232030 $ cat ./namespace3.php
<?php
namespace test;

class Blah { static function test() { echo "Test\n"; } }

call_user_func(array(NAMESPACE.'::Blah', 'test'));
?>

andrewm@ds38 /usr/local/src/php6.0-200707232030 $ ./sapi/cli/php ./namespace3.php
Test

Andrew Minerd
Software Architect
The Selling Source, Inc.

18 years ago by Larry Garfield — view source — reply

unread

On Tue, 24 Jul 2007 11:53:38 -0700

stas@zend.com (Stanislav Malyshev) wrote:

Where I can see a huge use for namespaces is plugin-based
architectures. Each plugin is its own namespace. If you have a list
of plugins, then you have a list of namespaces and can iterate over
that and invoke the same operation on each plugin. That would require
call_user_func() and call_user_func_array() and the rest of that family
to be able to handle namespaces. How would one

Since namespace is just a part of class name, I don't see any problem
for call_user_func() to be able to use namespaced names. Of course, they
should get full class name - if you want to use shorter ones you'd have
to change something. Here we might need some functionality, but it's not
clear to me yet which one.

w/ snapshot from yesterday:

andrewm@ds38 /usr/local/src/php6.0-200707232030 $ cat ./namespace3.php
<?php
namespace test;

class Blah { static function test() { echo "Test\n"; } }

call_user_func(array(NAMESPACE.'::Blah', 'test'));
?>

andrewm@ds38 /usr/local/src/php6.0-200707232030 $ ./sapi/cli/php
./namespace3.php Test

Mm, nice. And presumably the same would work for any other namespace, and for
functions as well as classes/objects.

That should make plugin architectures, both OO and non-OO, a lot cleaner.
Spiffy. :-)

Do __autoload() and the SPL autoload stack get namespace information as well?
I didn't get that from the mail archive link posted yesterday.

--
Larry Garfield AIM: LOLG42
larry@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

18 years ago by Stanislav Malyshev — view source — reply

unread

Do __autoload() and the SPL autoload stack get namespace information as well?
I didn't get that from the mail archive link posted yesterday.

Autoload should get full class names (with namespace).

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Stanislav Malyshev — view source — reply

unread

there is a NAMESPACE constant, which is nice. Is there also a way to get
the "full name" of a function or class, so you can see where it came from?
Does import work for functions as well as classes?

Inside namespace it's NAMESPACE.'::'.$short_name (yes, '::name'
would be the same as just 'name'). Outside there's currently no way to
do it automatically (i.e. resolve imports).

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Andrew Minerd — view source — reply

unread

Markus,

import Zend::DB;
import My::DB;
import Woot::Database as DB;

I don't quite understand your example.

The issue was that importing an entire namespace would introduce the possibility of name conflicts. My point was simply that conflicts could still exist, so that argument is pointless.

Andrew Minerd
Software Architect
The Selling Source, Inc.

On Mon, 23 Jul 2007 20:40:19 +0200
Markus Fischer markus@fischer.name wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andrew,

Andrew Minerd wrote:

Well, first of all, not exactly. I think you meant: not import everything from two or more namespaces with conflicting names. Secondly, that's not the only solution. You could import everything from one, and not import from the other (or use a shorter prefix). Thirdly, you're not preventing collisions at all:

import Zend::DB;
import My::DB;
import Woot::Database as DB;

I don't quite understand your example. When I look at it in real life, I
would go for:

import Zend::DB as ZBD;
import My::DB as MDB;
import Woot::Database as DB;

I mean, that's is the point, to have more readable code == shorter
identifiers, isn't it?

So your code continues to read (just made up):

$oZdb = ZDB::factor('mysql');
$oMdb = MDB::getInstance('oracle');
$oWdb = DB::getDriver('postgres');

instead of:

$oZdb = Zend::DB:factor...
$oMdb = My::DB::getInstance
$oWdb = Woot::Database::getDriver..

Isn't that a win, at last?

That's how I understood. Maybe I got that wrong.

Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpPYT1nS0RcInK9ARAmQmAKDGsYj/ZY0FNojQobKb3bK2NL6QDgCcDKgl
LnyIP65ymnx180f7/WD5WfM=
=LjpG
-----END PGP SIGNATURE

18 years ago by Stanislav Malyshev — view source — reply

unread

The issue was that importing an entire namespace would introduce the
possibility of name conflicts. My point was simply that conflicts
could still exist, so that argument is pointless.

No, it's not, because under my scheme you can easily resolve the
conflict by using different aliases. When you import whole bunch of
classes into global space, you don't know what names would be so you
can't alias those of them which are colliding.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Stanislav Malyshev — view source — reply

unread

That's how I understood. Maybe I got that wrong.

You got it right.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Stanislav Malyshev — view source — reply

unread

Well, first of all, not exactly. I think you meant: not import
everything from two or more namespaces with conflicting names.

No, not import everything from any namespaces at all, because enabling
it brings more problems than use and is totally unnecessary.

Thirdly, you're not preventing collisions at all:

import Zend::DB; import My::DB; import Woot::Database as DB;

This should give an error, just as duplicate class or function
definition does. If it doesn't right now, it should be fixed.

And what of applications that use libraries without any conflicting
names? Let's just be honest about what you're saying: this patch is
intentionally crippled.

I am honest and it is not crippled. There is a functionality that does
more harm than good (e.g. - ability to access random memory address) and
so this patch does not provide it.

The application does? No: the library does. Currently, an application
that is using two libraries with conflicting names can do nothing to
resolve the conflicts. With namespace imports (barring a namespace
collision), the application chooses how it's going to reference the
names within a given library.

I'm afraid you lost me here. What exactly application is supposed to do?

No: that comes from applying imports at run-time. A "blanket" import
could only be applied to classes available at compile time. Granted,
that'd be somewhat confusing, but, at the very least, address the
proper issue.

You can't imagine how broken that would be - since many classes can be
resolved at compile or run-time based on dependencies to other classes,
load order, config values, etc. which can in turn be based on
dependencies on yet another things. So you'd have absolutely no way to
know what you are importing and you'll be constantly bitten by changes
in totally unrelated code which will break your imports since some class
once was resolved compile-time and now is runtime-loaded or vice versa,
or somebody changed load order in some unrelated files.
On top of that, most PHP programmers have no idea about this whole
compile/runtime class definition thing, so trying to explain them why
their class failed to import would not be an easy task. And PHP is
supposed to be easy. I can describe current model in general in about 4
lines. Can you describe yours?

That's only one problem with blanket imports.

So..... What are the others?

Polluting global space. Unfriendliness to bytecode caches - note that if
you resolve names while compiling file and allow to import without
specifying what exactly are the names you are importing it means now the
current file code depends on each and every file that belongs to the
namespace, and if you add another file to the namespace you'd have to
rebuild all files that ever imported this namespace.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Rasmus Lerdorf — view source — reply

unread

Stanislav Malyshev wrote:

Compile-time resolution means you don't get performance penalty for
namespaces when you are not using it, and have very low costs when you
do use it. Allowing blanket imports means we don't know what "new Foo()"
means until it is executed - meaning we need to make extra lookups on
each class fetch, even if the code doesn't use namespaces at all. That's
only one problem with blanket imports.

And a fatal one in my book. For the folks arguing so passionately about
this namespace implementation, try to consider the compiler vs. executor
issues involved. We really need to stop the trend of pushing everything
down into the executor.

-Rasmus

18 years ago by Matthew Kavanagh — view source — reply

unread

Rasmus Lerdorf wrote:

Stanislav Malyshev wrote:

Compile-time resolution means you don't get performance penalty for
namespaces when you are not using it, and have very low costs when you
do use it. Allowing blanket imports means we don't know what "new Foo()"
means until it is executed - meaning we need to make extra lookups on
each class fetch, even if the code doesn't use namespaces at all. That's
only one problem with blanket imports.

And a fatal one in my book. For the folks arguing so passionately about
this namespace implementation, try to consider the compiler vs. executor
issues involved. We really need to stop the trend of pushing everything
down into the executor.

-Rasmus

The compile time vs. execution time argument may be a good one against
global import and against other crazy ideas in my head (like allowing
statements in namespaces).

But why not allow importing namespaced functions and constants into the
global namespace?

If this were added then "blanket import" could be left to the intrepid
and foolhardy programmer to do manually. It'd just end up being
boilerplate and if someone really objects to some extra lines they could
add an explicit fold in their editor to hide it.

18 years ago by Rasmus Lerdorf — view source — reply

unread

Matthew Kavanagh wrote:

Rasmus Lerdorf wrote:

Stanislav Malyshev wrote:

Compile-time resolution means you don't get performance penalty for
namespaces when you are not using it, and have very low costs when you
do use it. Allowing blanket imports means we don't know what "new Foo()"
means until it is executed - meaning we need to make extra lookups on
each class fetch, even if the code doesn't use namespaces at all. That's
only one problem with blanket imports.

And a fatal one in my book. For the folks arguing so passionately about
this namespace implementation, try to consider the compiler vs. executor
issues involved. We really need to stop the trend of pushing everything
down into the executor.

-Rasmus

The compile time vs. execution time argument may be a good one against
global import and against other crazy ideas in my head (like allowing
statements in namespaces).

But why not allow importing namespaced functions and constants into the
global namespace?

If this were added then "blanket import" could be left to the intrepid
and foolhardy programmer to do manually. It'd just end up being
boilerplate and if someone really objects to some extra lines they could
add an explicit fold in their editor to hide it.

As long as it doesn't go into the global namespace directly. As in:

namespace foo;
class bar1 {
...
}
class bar2 {
...
}

import foo:* as myfoo

gives you:

myfoo:bar1 and myfoo:bar2
and not bar1 and bar2 directly in the global namespace. The latter is a
performance killer across the board but I see no issue with the former.

-Rasmus

18 years ago by Stanislav Malyshev — view source — reply

unread

But why not allow importing namespaced functions and constants into the
global namespace?

Because there's really no need to. Nothing wrong with
namespace::function().

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Sebastian Mendel — view source — reply

unread

Stanislav Malyshev schrieb:

But why not allow importing namespaced functions and constants into
the global namespace?

Because there's really no need to. Nothing wrong with
namespace::function().

so i can not use a lib that switched to namespaces in my old code that does
not support namespace?

with other words:

i have to rewrite my whole code to use the new version of a lib that has
switched to namespace?

thats makes transition really easy ... so why should any lib switch to
namespace if this implies all apps using this libarary needs to rewrite
their code?

--
Sebastian

18 years ago by Alexey Zakhlestin — view source — reply

unread

This is a step which should be made between major versions, and major
versions are meant to be incompatible in some ways…

anyway, grepping a project and changing class-names is a manageable task

Stanislav Malyshev schrieb:

But why not allow importing namespaced functions and constants into
the global namespace?

Because there's really no need to. Nothing wrong with
namespace::function().

so i can not use a lib that switched to namespaces in my old code that does
not support namespace?

with other words:

i have to rewrite my whole code to use the new version of a lib that has
switched to namespace?

thats makes transition really easy ... so why should any lib switch to
namespace if this implies all apps using this libarary needs to rewrite
their code?

--
Sebastian

--

--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/

18 years ago by Stanislav Malyshev — view source — reply

unread

so i can not use a lib that switched to namespaces in my old code that
does not support namespace?

You definitely can. You'd have to use names like A::B::C instead of
A_B_C but if the library "switched" then you probably expect some
change, right?

i have to rewrite my whole code to use the new version of a lib that has
switched to namespace?

You'd have to do search-and-replace for _ to ::, yes.

thats makes transition really easy ... so why should any lib switch to
namespace if this implies all apps using this libarary needs to rewrite
their code?

Because it makes using library easier. If it isn't good for you, don't
switch :) The rest of PHP isn't going to disappear, you still can use it.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Richard Lynch — view source — reply

unread

Stanislav Malyshev schrieb:

But why not allow importing namespaced functions and constants into
the global namespace?

Because there's really no need to. Nothing wrong with
namespace::function().

so i can not use a lib that switched to namespaces in my old code that
does
not support namespace?

with other words:

i have to rewrite my whole code to use the new version of a lib that
has
switched to namespace?

thats makes transition really easy ... so why should any lib switch to
namespace if this implies all apps using this libarary needs to
rewrite
their code?

Since a "code rewrite" consists of slapping "<?php package foo;?>" or
something similar at the top of each file, and even a moron like me
could manage that in a very short time, I don't think this is much of
an issue, personally.

There will be many who won't use namespaces/packages/whatevers until
all "live" versions of PHP support them. That's just the nature of the
beast.

--
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?

18 years ago by Stanislav Malyshev — view source — reply

unread

Or, in my dream world of PHP being unique:
import LibB (-Date);
import LibB::Date as BDate;

next would be:
SELECT class FROM LibB WHERE class.name NOT LIKE 'Date%' AND
class.version < 3.14 OR class.approved='Manager'
Maybe we should use PDO to support these? ;)

I don't think it works well at all for the unwashed masses that just
want to get the job done with minimum fuss -- which is what PHP was
originally all about :-)

Unwashed masses did 10 years fine without it :)

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

18 years ago by Stefan Priebsch — view source — reply

unread

Stanislav Malyshev schrieb:

SELECT class FROM LibB WHERE class.name NOT LIKE 'Date%' AND
class.version < 3.14 OR class.approved='Manager'
Maybe we should use PDO to support these? ;)

For performance reasons, I would rather suggest using native database
APIs instead of PDO. When do you think you can have the patch ready?

;-)

Kind regards,

Stefan

--

e-novative> - We make IT work for you.

e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch

http://www.e-novative.de

18 years ago by Sebastian Mendel — view source — reply

unread

Stefan Priebsch schrieb:

Stanislav Malyshev schrieb:

SELECT class FROM LibB WHERE class.name NOT LIKE 'Date%' AND
class.version < 3.14 OR class.approved='Manager'
Maybe we should use PDO to support these? ;)

For performance reasons, I would rather suggest using native database
APIs instead of PDO. When do you think you can have the patch ready?

;-)

storing the source in a database would be nice, would make many things much
easier ... all this inlcude_path issues, searching, indexing (functions,
classes), scopes, grouping (namespaces, packages), documenting, moving,
defining dependencies, ...

LOAD FROM function
WHERE 'string' IN (param_type)
AND return = 'array'
AND function = 'split'

LOAD FROM function
WHERE group = 'date'

...

;-)

--
Sebastian

18 years ago by Richard Lynch — view source — reply

unread

Or, in my dream world of PHP being unique:
import LibB (-Date);
import LibB::Date as BDate;

next would be:
SELECT class FROM LibB WHERE class.name NOT LIKE 'Date%' AND
class.version < 3.14 OR class.approved='Manager'
Maybe we should use PDO to support these? ;)

No, I think that if I need to use a DB to manage my package names, I
could do it just fine IF sufficient granularity is provided as
above.

But there's no such ability at this time, which makes it pretty
unsuitable for the 90%, imho.

I don't think it works well at all for the unwashed masses that just
want to get the job done with minimum fuss -- which is what PHP was
originally all about :-)

Unwashed masses did 10 years fine without it :)

So we don't need namespaces at all? :-)

If we need them, shouldn't they be useful to the 90% instead of only
the 10%?

Or is this an "advanced feature" that only the 10% should even use?

Shall we document it as such?

--
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?

Question about Namespace patch

I think there should be.

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 :)

works differently :)

works differently :)

works differently :)

No, incorrect. The main blocker was that all other implementations were either inconsistent, hurting performance or too complex for PHP.

Brian Moon Senior Developer

regards, Derick

Brian Moon Senior Developer

regards, Derick

regards, Derick

regards, Derick

I agree, but I don't agree that sum of votes is a good way to reach a good decision in this case.

while in Python module is file and package is directory. Also, Java is a compiled language - meaning you have much more information in compile time than with PHP - all classes you use are to be known compile-time.

I don't see any imports involving * happening, since they all have a common problem - you don't know what you are importing. Fortunately, they also are completely unnecessary - if you need all things inside Foo, why won't you just refer to them as Foo::things?

I don't see any imports involving * happening, since they all have a common problem - you don't know what you are importing. Fortunately, they also are completely unnecessary - if you need all things inside Foo, why won't you just refer to them as Foo::things?

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.

Autoload should get full class names (with namespace).

No, it's not, because under my scheme you can easily resolve the conflict by using different aliases. When you import whole bunch of classes into global space, you don't know what names would be so you can't alias those of them which are colliding.

Because it makes using library easier. If it isn't good for you, don't switch :) The rest of PHP isn't going to disappear, you still can use it.

Unwashed masses did 10 years fine without it :)

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 :)

No, incorrect. The main blocker was that all other implementations were
either inconsistent, hurting performance or too complex for PHP.

Brian Moon
Senior Developer

regards,
Derick

Brian Moon
Senior Developer

regards,
Derick

regards,
Derick

regards,
Derick

I agree, but I don't agree that sum of votes is a good way to reach a
good decision in this case.

while in Python module is file and package is directory. Also, Java is a
compiled language - meaning you have much more information in compile
time than with PHP - all classes you use are to be known compile-time.

I don't see any imports involving * happening, since they all have a
common problem - you don't know what you are importing. Fortunately,
they also are completely unnecessary - if you need all things inside
Foo, why won't you just refer to them as Foo::things?

I don't see any imports involving * happening, since they all have a
common problem - you don't know what you are importing. Fortunately,
they also are completely unnecessary - if you need all things inside
Foo, why won't you just refer to them as Foo::things?

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.

No, it's not, because under my scheme you can easily resolve the
conflict by using different aliases. When you import whole bunch of
classes into global space, you don't know what names would be so you
can't alias those of them which are colliding.

Because it makes using library easier. If it isn't good for you, don't
switch :) The rest of PHP isn't going to disappear, you still can use it.