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 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 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
Your answered like "We are not like C#, but we are like Python.". I'm
not the one that will point that Python always try to be a unique
language or will criticize you.
We are not like Python either, really. We try to do what's best for PHP
with it's unique history, usage patterns and problems.
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
Hi,
At first "import Zend::DB" is equivalent of "import Zend:DB as DB";
-Original Message-
> From: Arpad Ray [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 23, 2007 8:37 PM
> To: [EMAIL PROTECTED]
> Cc: 'Hans Lellelid'; 'PHP internals'
> Subject: RE: [PHP-DEV] Simple Namespace Proposal
> -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
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
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: Jeremy
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
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 b
>
> 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"
We are not C++. Python doesn't use braces.
The only neediness for braces is placing several namespaces into one file,
but one of
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
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
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
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.
F
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
+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 disc
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-dev&m=118355320225178&w=2
Maybe also need README and FAQ on that too, and eventually a m
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 b
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 gue
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
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 expl
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
> -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 Sto
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
-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 h
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
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 expla
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
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
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 n
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
const
On 7/23/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
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
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 down/me
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 loadin
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
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, 200
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 fo
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: PHPd
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 HEA
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)
=
> 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
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
In reality, it is rarely (almost never) needed to import all the
classes. Usually you need 2–4 per file, not more, and importing just
what you really need is the step to a clean design.
You don't need to import every class which is used implicitly, only
those which are explicitly used.
On 7/23/
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
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
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:[EMAIL PROTECTED]
Sent: Monday, July 23, 2007 12:55 AM
To: Stanislav Malyshev
Cc: Markus
68 matches
Mail list logo
