On 8/21/07, Gregory Beaver <[EMAIL PROTECTED]> wrote:
> Hi again,
>
> The attached patch:
> 1) adds "unset import" syntax for declaring a namespace to have local
> import scope (it does NOT affect variable scope or the global
> class/function table)
huh ? o_O unset import ? that's really weird.
-
Stanislav Malyshev wrote:
>>
>> namespace __::__main;
>> function thing() {}
>> one::thing();
>> ?>
>
> __::__ look like some weird ASCII art, maybe we need something better
> for it.
:)
it could be anything, really, I just figured there's no chance that
would conflict with any other namespace.
The purpose of all my patches is to make it possible to combine multiple
namespaces into a single file. It looks like namespace {} syntax
introduces much more trouble than it is worth.
Heh, why do you think we chose not to do it - because we are
bracketophobic bigots? ;)
file2.php:
Not s
Stanislav Malyshev wrote:
>> 1) adds "unset import" syntax for declaring a namespace to have local
>> import scope (it does NOT affect variable scope or the global
>> class/function table)
>
> I don't like it. What's "unset import"? Seems to be very artificial
> concept.
>
>> be as intuitive as pos
The latter would be hard to do since class definition is a runtime
Read "compile-time" here :)
thing. Unless we make all classes be defined in runtime (and accept
slowdown following from it) we don't have any point in time where class
constants could be defined. Also, we don't have a good way
We do have runtime constants created with define(), so the critical need
in runtime namespace constants is quite questionable to me.
"Critical need" is a matter of definition. You can do
define(__NAMESPACE__.'::foo', 'bar') but frankly, it sucks. const foo =
'bar' looks so much better. That sa
I propose to define these constants in compile time or change class
constants to be defined in runtime.
The latter would be hard to do since class definition is a runtime
thing. Unless we make all classes be defined in runtime (and accept
slowdown following from it) we don't have any point in
On 22.08.2007 22:25, Stanislav Malyshev wrote:
We do have runtime constants created with define(), so the critical need
in runtime namespace constants is quite questionable to me.
"Critical need" is a matter of definition. You can do
define(__NAMESPACE__.'::foo', 'bar') but frankly, it sucks.
On 22.08.2007 21:50, Stanislav Malyshev wrote:
I don't think it's _required_ for the constants to be useful.
Well, depends on how you define requirements. Having out-of-class
constants is not required either - Java does fine without it :) However,
thinking about how people would use namespace
Which basically means class constants are useless in their current
state, right?
No, they are useful for some things (pre-defined values) and useless for
others (expressions). The problem is that in classes we can do these
other things - with variables. And in global space, with define(). In
On 22.08.2007 21:08, Stanislav Malyshev wrote:
Don't you think it's bad idea to use the same 'const' syntax, but
different behavior?
I believe it would be really confusing for users, as class constants are
set in compile time, thus 'const DIR = dirname(__FILE__);' is not possible.
That's a goo
The correct URL is http://grasp.coresecurity.com
Ezequiel Gutesman wrote:
> CORE GRASP for PHP is a web-application protection software aimed at
> detecting and blocking injection vulnerabilities and privacy violations.
> As mentioned during its presentation at Black Hat USA 2007, GRASP is
> being
Don't you think it's bad idea to use the same 'const' syntax, but
different behavior?
I believe it would be really confusing for users, as class constants are
set in compile time, thus 'const DIR = dirname(__FILE__);' is not possible.
That's a good point. However, "constant constants" - i.e., o
"Jani Taskinen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "package" is also shorter than "namespace". Just commit the stuff, it's
> pointless to argue about it. Majority rules.
and it makes for great alliteration
can you say "Peter picked a Pack of Pecl PHP Packages" ;-)
--
Why can't the unicode switch be turn on/off by the application when needed?
Perhaps have an on/off/auto setting where auto meaning it'll remain off
unless the application explicitly asks for it.
Because it's very hard to implement since we'd have to keep 2 copies of
all symbol tables.
--
Stani
CORE GRASP for PHP is a web-application protection software aimed at
detecting and blocking injection vulnerabilities and privacy violations.
As mentioned during its presentation at Black Hat USA 2007, GRASP is
being released as open source under the Apache 2.0 license and can be
obtained from http
1) adds "unset import" syntax for declaring a namespace to have local
import scope (it does NOT affect variable scope or the global
class/function table)
I don't like it. What's "unset import"? Seems to be very artificial concept.
be as intuitive as possible. Having a separate scope by defaul
On 8/22/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> We are working on this feature and additional patch will be posted for
> review on this week.
>
> Thanks. Dmitry.
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of David Coallier
> > Sent: F
On 8/22/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> We never resolved constants in compile time,
I know that, hence my "see pecl hidef" comment.
> because constants' values may
> be unknown in compile time.
The idea behind that was to get constants like internal constants. If
it is a integer
Good point.
We'll need to discuss this.
Thanks. Dmitry.
> -Original Message-
> From: Antony Dovgal [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 22, 2007 5:21 PM
> To: Dmitry Stogov
> Cc: 'Johannes Schlьter'; 'PHP Internals List'
> Subject: Re: [PHP-DEV] Constants in namesapces
>
We never resolved constants in compile time, because constants' values may
be unknown in compile time.
Thanks. Dmitry.
> -Original Message-
> From: Pierre [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 22, 2007 5:12 PM
> To: Dmitry Stogov
> Cc: Johannes Schlьter; PHP Internals List
On Wed, 2007-08-22 at 16:15 +0200, Lukas Kahwe Smith wrote:
> Robert Cummings wrote:
> > On Wed, 2007-08-22 at 13:57 +0200, Marcus Boerger wrote:
> >> Hello Rasmus,
> >>
> >>the limitations given here and very good explained should imo stay. They
> >> should because that is not only easier to u
Robert Cummings wrote:
On Wed, 2007-08-22 at 13:57 +0200, Marcus Boerger wrote:
Hello Rasmus,
the limitations given here and very good explained should imo stay. They
should because that is not only easier to understand and easier for anything
that has to deal with it like opcode caches and
On Wed, 2007-08-22 at 13:57 +0200, Marcus Boerger wrote:
> Hello Rasmus,
>
>the limitations given here and very good explained should imo stay. They
> should because that is not only easier to understand and easier for anything
> that has to deal with it like opcode caches and whatnot but also
yes. keep it consistent. if that means sacrificing features, so be it.
David
Am 22.08.2007 um 15:20 schrieb Antony Dovgal:
On 22.08.2007 17:03, Dmitry Stogov wrote:
You can have "const" outside namespaces but they are not real
compile-time
constants.
They are set during execution in the
On 22.08.2007 17:03, Dmitry Stogov wrote:
You can have "const" outside namespaces but they are not real compile-time
constants.
They are set during execution in the same way as define() does.
Don't you think it's bad idea to use the same 'const' syntax, but different
behavior?
I believe it w
On 8/22/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> You can have "const" outside namespaces but they are not real compile-time
> constants.
> They are set during execution in the same way as define() does.
>
> const DIR = dirname(__FILE__);
> echo DIR;
> ?>
Off topic but this const makes me th
You can have "const" outside namespaces but they are not real compile-time
constants.
They are set during execution in the same way as define() does.
Thanks. Dmitry.
> -Original Message-
> From: Johannes Schlьter [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 22, 2007 4:48 PM
> To
Hi Andi,
Am 21.08.2007 um 21:32 schrieb Andi Gutmans:
If there's an overwhelming support for removing the switch then I
guess
that's where it is. I still think it's a mistake and we are risking a
big split in the user base going forward but time will tell. Long term
PHP may not recover from t
Hi Dmitry,
On Wed, 2007-08-22 at 13:02 +0400, Dmitry Stogov wrote:
> Hi,
>
> The proposed patch implements namespace support for constants.
> It allows to declare constants in namespaces in the same way as in classes.
> And these constants may be used in the same may as namespaces' functions.
I
Why can't the unicode switch be turn on/off by the application when needed?
Perhaps have an on/off/auto setting where auto meaning it'll remain off
unless the application explicitly asks for it.
On 8/21/07, Larry Garfield <[EMAIL PROTECTED]> wrote:
>
> Andi,
>
> Is there a guide somewhere for thos
Hello Rasmus,
the limitations given here and very good explained should imo stay. They
should because that is not only easier to understand and easier for anything
that has to deal with it like opcode caches and whatnot but also adhrers to
the good old KISS approach of PHP.
That said, instead
Hello Dmitry,
so please stick to your own arguments and don't chnage them at random. And
spare us with stupid arguemnts. The renaming patch was perfectly valid when
offered and I am sure the author of that patch would fix it before comitting
if allowed to. So saying that the patch is wrong just
On Wed, 22 Aug 2007, M. Sokolewicz wrote:
> I'm not sure if this is the best way to take it, to be honest I had to
> re-read your post 2x to figure out what was actually going on and why.
> The unset import part is odd and not very transparent to the average
> user (imo). Sure, with good docume
Gregory Beaver wrote:
Hi again,
The attached patch:
1) adds "unset import" syntax for declaring a namespace to have local
import scope (it does NOT affect variable scope or the global
class/function table)
2) removes "namespace Name;" syntax (this I am happy to add this back in
if there is uproa
Hi,
The proposed patch implements namespace support for constants.
It allows to declare constants in namespaces in the same way as in classes.
And these constants may be used in the same may as namespaces' functions.
I am going to commit this patch on Friday.
Any objections?
Thanks. Dmitry.
36 matches
Mail list logo
