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
On Wed, July 25, 2007 10:27 am, Sebastian Mendel wrote:
> 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 th
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
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
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 n
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
On 7/25/07, Sebastian Mendel <[EMAIL PROTECTED]> wrote:
Stanislav Malyshev schrieb:
>> But why not
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 namespac
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:
>
>
> include "MyClass.php";
> import MyClass;
>
> ?>
>
> Then why use a
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
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
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 PROTECTED]
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 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/
(408)253-88
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
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 ov
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_use
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
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 - mean
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
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. Yo
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
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__ const
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
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: http://www.php.net/un
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
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 col
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
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
-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
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,
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
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; namespace
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 thin
On Mon, 23 Jul 2007 10:02:43 -0700
[EMAIL PROTECTED] (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 l
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
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
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
Vendor
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 sto
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
m
007 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 discussio
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 p
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:
Then why use a namespace? I really don't see the point. Namespaces are
doin
--
From: [EMAIL PROTECTED] [mailto:[EMAIL 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
ehalf 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 wan
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 you
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 k
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
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:
Then why use a namespace? I really don't see the point. Namespaces are
doing nothing for you in this case.
--
Brian Moon
Sen
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
> >
> > Wh
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
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 in
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 abou
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 o
> 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 d
---
Jeremy Privett
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 p
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.
N
ion 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:[EMAIL PROTECTED]
Sent: Monday, July 23, 2007 1:39 AM
To: Jeremy Privett
Cc: Derick Rethans; Markus F
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
2) How can I import all classes from a namespace at once?
Use namespace::class.
That's not the answer to the question. Markus was asking how to import
*all* classes from a namespace at *once*.
That IS the answer. You don't. You use namespace::class instead. The
whole purpose was to get them
shev
Cc: Markus Fischer; internals
Subject: Re: [PHP-DEV] Question about Namespace patch
On Sun, 22 Jul 2007, Stanislav Malyshev wrote:
> > 2) How can I import all classes from a namespace at once?
>
> Use namespace::class.
That's not the answer to the question. Markus was ask
On Sun, 22 Jul 2007, Stanislav Malyshev wrote:
> > 2) How can I import all classes from a namespace at once?
>
> Use namespace::class.
That's not the answer to the question. Markus was asking how to import
*all* classes from a namespace at *once*.
Derick
--
Derick Rethans
http://derickrethan
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
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
64 matches
Mail list logo
