On Wed, July 25, 2007 2:10 pm, Stanislav Malyshev wrote:
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
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
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
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
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
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
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 -
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
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
On Tue, 24 Jul 2007 11:53:38 -0700
[EMAIL PROTECTED] (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
On Tuesday 24 July 2007, Andrew Minerd wrote:
On Tue, 24 Jul 2007 11:53:38 -0700
[EMAIL PROTECTED] (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
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
[EMAIL PROTECTED] http://www.zend.com/
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
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
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL
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
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.
On Mon, July 23, 2007 9:52 am, Brian Moon wrote:
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
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
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
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
, right now.
Thanks.
---
Jeremy Privett
Software Developer
Peak8 Solutions
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Monday, July 23, 2007 1:39 AM
To: Jeremy Privett
Cc: Derick Rethans; Markus Fischer; internals
Subject: Re: [PHP-DEV] Question about
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
Software Developer
Peak8 Solutions
-Original Message-
From: Alexey Zakhlestin [mailto:[EMAIL PROTECTED]
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
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
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
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
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
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
On Mon, 23 Jul 2007, David Zülke wrote:
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
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
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
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
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
, 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
PROTECTED] 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
On 7/23/07, Brian Moon [EMAIL PROTECTED] wrote:
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
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
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
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
On Mon, 23 Jul 2007, Nicolas Bérard-Nault wrote:
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
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
On Mon, 23 Jul 2007 11:08:58 -0700
[EMAIL PROTECTED] (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,
-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
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
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
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
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
That's how I understood. Maybe I got that wrong.
You got it right.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
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
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__
On 7/24/07, Stanislav Malyshev [EMAIL PROTECTED] 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
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
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
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
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
55 matches
Mail list logo
