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
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
In reality, it is rarely (almost never) needed to import all the
classes. Usually you need 2–4 per file, not more, and importing just
what you really need is the step to a clean design.
You don't need to import every class which is used implicitly, only
those which are explicitly used.
On
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
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
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (624 total including feature requests)
===[*Programming Data Structures]=
40496 Assigned Test bug35239.phpt still fails (works in PHP 5)
There is no way to put this patch into 5.2.
Dmitry.
-Original Message-
From: Timm Friebe [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 21, 2007 1:58 PM
To: PHPdev
Subject: [PHP-DEV] Namespaces patch backport
Hi,
I've backported the namespaces patch to current CVS HEAD. Here
Exactly, it will go to 5.3 of course.
--Jani
On Mon, 2007-07-23 at 13:06 +0400, Dmitry Stogov wrote:
There is no way to put this patch into 5.2.
Dmitry.
-Original Message-
From: Timm Friebe [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 21, 2007 1:58 PM
To: PHPdev
Sebastian Deutsch wrote:
hello,
is there a patch for the proposal out there? is anyone working on that
problem?
There might be a patch flying around ...
Last I heard from Marcus was that it seems impossible to find a solution
for this without accepting a slow down/memory footprint increase
Hi Arpad,
You have to always use namespace name as prefix for acesing namespace
entities.
(The only exception is direct import of calss).
So expectatins in your tests are wrong.
Thanks. Dmitry.
-Original Message-
From: Arpad Ray [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 15, 2007
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
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (49 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
27372 Verified parse error
Lukas Kahwe Smith wrote:
Sebastian Deutsch wrote:
hello,
is there a patch for the proposal out there? is anyone working on
that problem?
There might be a patch flying around ...
Last I heard from Marcus was that it seems impossible to find a solution
for this without accepting a slow
I've taken my original nowdocs patch and revamped it to be much more
efficient and functional. This version:
- Parses nowdocs as constant strings rather than ADD_STRING opcodes.
- Allows the flex scanner do less work.
- Enables nowdocs to be used in static_scalar contexts, such as class
Patch applied to both PHP_5_2 and HEAD. Thanks!
--Jani
On Sat, 2007-07-21 at 21:57 +0200, Mattias Bengtsson wrote:
As stated in the manual for str_pad() If the value of pad_length is
negative or less than the length of the input string, no padding takes
place..
By using a very low
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
OK... internals-newb question. Doesn't backporting everything from 6.x to 5.x
except Unicode automatically undermine PHP 6 adoption? If PHP 5.5 ends up
being practically identical to PHP 6 unicode=off because everything has been
backported... what's the incentive for PHP 6 unicode=off to even
1) Do we have unnamed namespaces available ?
I'm not sure what it is but most probably no.
2) In short and clear, why are braces not being used ? C++, C# uses
it. (Short answer and if the answer is Developer didn't want to do
it... just say Usual
PHP is not C++, C#. For the rest of
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
David Coallier wrote:
Should be ok for a first draft and this is not some sort of attack, I
am really trying to compile a list of features absent and present to
see what *types* of namespaces we have and how to correctly inform
people on how
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
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Coallier
Sent: Monday, July 23, 2007 4:31 PM
To: Dmitry Stogov
Cc: Arpad Ray; Hans Lellelid; PHP internals
Subject: Re: [PHP-DEV] Simple Namespace Proposal
On 7/23/07, Dmitry Stogov
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
Am 23.07.2007 um 16:44 schrieb Dmitry Stogov:
It is not the first namespace proposal.
I made three different concept and saw two other concepts in the
past .
This one seems as most awaitble by most PHP users.
This is a pretty random guess, but I'd say people are so tired of
having to
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
On 7/23/07, David Zülke [EMAIL PROTECTED] wrote:
Am 23.07.2007 um 16:44 schrieb Dmitry Stogov:
It is not the first namespace proposal.
I made three different concept and saw two other concepts in the
past .
This one seems as most awaitble by most PHP users.
This is a pretty random guess,
A suggestion: allow anyone to reopen bugs marked no feedback. Also
allow anyone to switch a bug from feedback to open.
The PHP bug tracker could go a long way towards liberalisation.
Community involvement seems to be actively discouraged. I'd like to see
some more sweeping changes. But I'd be
I've the same problem: the patch is there but no real information how
it's supposed to work, i.e. expected feature set. I mean, in one place.
A Wiki would be nice ;-)
It's here:
http://marc.info/?l=php-devm=118355320225178w=2
Maybe also need README and FAQ on that too, and eventually a
+1
David
Am 23.07.2007 um 17:43 schrieb Tim Starling:
A suggestion: allow anyone to reopen bugs marked no feedback. Also
allow anyone to switch a bug from feedback to open.
The PHP bug tracker could go a long way towards liberalisation.
Community involvement seems to be actively
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
On 23.07.2007 19:43, Tim Starling wrote:
There aren't even any relevant contact details
available to draw the attention of admins to the bug that needs reopening.
This is simply not true. Every time someone changes status of the report
(even with the canned reply) the system logs his email.
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
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
On 7/23/07, Jeremy Privett [EMAIL PROTECTED] wrote:
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
On Mon, 2007-07-23 at 16:43 +0100, Tim Starling wrote:
A suggestion: allow anyone to reopen bugs marked no feedback. Also
allow anyone to switch a bug from feedback to open.
You're free to add comments to those. Do that and send an email to the
person who requested feedback. There will be no
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
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:[EMAIL PROTECTED]
Sent: Monday, July 23, 2007 10:43 AM
To:
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
-Original Message-
From: Guilherme Blanco [mailto:[EMAIL PROTECTED]
Sent: Monday, July 23, 2007 8:21 PM
To: David Coallier
Cc: David Zulke; Dmitry Stogov; Arpad Ray; Hans Lellelid; PHP
internals
Subject: Re: [PHP-DEV] Simple Namespace Proposal
2) In short and clear,
Hi,
At first import Zend::DB is equivalent of import Zend:DB as DB;
?php
require 'Zend/Db/Connection.php';
import Zend::DB;
After these statement you can use any classes and functions from Zend::DB
namespace qualifying them by prefix DB::.
$x = DB::Connection();
Thanks. Dmitry.
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 10:43 am, Tim Starling wrote:
A suggestion: allow anyone to reopen bugs marked no feedback. Also
allow anyone to switch a bug from feedback to open.
I believe this idea has a great deal of merit, unless it has proven to
be subject to abuse in the past or something.
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
59 matches
Mail list logo
