On Fri, 25 Nov 2005, Pierre wrote:
> > Just to clarify, it was Ilia who enabled the class, but just to move
> > the constants there. All methods are still disabled.
>
> He did it on Derick's demand. Ilia's mistake was to trust him. As Andi
> did too.
Since when do you think for Ilia? Your statem
On Fri, 25 Nov 2005, Andi Gutmans wrote:
> I must say that I feel deceived by this.
> Derick and I agreed that this won't be enabled for 5.1, and he then took
> advantage of the fact that release managers changed to enable his class.
> Doesn't leave a good taste in my mouth and it shouldn't happen
when it was first tried in
the early 5.0 development.
Bob Silva
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 28, 2005 2:43 PM
> To: Bob Silva
> Cc: 'Jessie Hernandez'; internals@lists.php.net
> Subject: Re: [PHP-DEV]
Have a fresh look :)
name1:::name2:::class::func();
name1::name2::class::func();
name1\name2\class::func();
I think there are way too many dots with ':::'.
Looking at this example I must say '\' looks cleanest. And it's the most
intuitive since namespaces are sort of like directories anywa
ms with
> > implementation... thanks for an explanation.
>
> > Bob
>
> > -Original Message-
> > From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> > Sent: Monday, November 28, 2005 12:26 PM
> > To: Jessie Hernandez
> > Cc: internals@lists.p
for an explanation.
> Bob
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 28, 2005 12:26 PM
> To: Jessie Hernandez
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out
&
Hello Markus,
Monday, November 28, 2005, 11:22:03 PM, you wrote:
> Marcus Boerger wrote:
>> Hello Stanislav,
>> Monday, November 28, 2005, 9:10:55 PM, you wrote:
>>>Why should it be final? Extending it won't do any problem AFAIU.
>>
>> If it is not final you could derive the config class and th
Marcus Boerger wrote:
Hello Stanislav,
Monday, November 28, 2005, 9:10:55 PM, you wrote:
Why should it be final? Extending it won't do any problem AFAIU.
If it is not final you could derive the config class and then instanciate
it. Static classes which nicely fit into configuration stuff can n
5 12:26 PM
> To: Jessie Hernandez
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out
> there)
>
> Hello Jessie,
>
> yes and no. During 5.0 development i had private and protected
inheritance
> already and we vo
05 12:26 PM
To: Jessie Hernandez
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out
there)
Hello Jessie,
yes and no. During 5.0 development i had private and protected inheritance
already and we voted against them. So i think we would vote ag
> I thought that was the whole point of namespaces. That you can include
> stuff without worries that things will conflict:
>
> namespace name1 {
>define("CONSTANT", "Hello world.");
> }
>
> namespace name2 {
>define("CONSTANT", "Hello mars.");
> }
>
> Would produce seporate constants becau
I thought that was the whole point of namespaces. That you can include
stuff without worries that things will conflict:
namespace name1 {
define("CONSTANT", "Hello world.");
}
namespace name2 {
define("CONSTANT", "Hello mars.");
}
Would produce seporate constants because they're defined in
, November 28, 2005 11:55 AM
To: Stanislav Malyshev
Cc: 'PHP internals'
Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out
there)
Hello Stanislav,
easy changing of behavior in classes of a namespace by only changing one
value for instance.
namespace Foo
{
cons
Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 28, 2005 11:23 PM
> To: Dmitry Stogov
> Cc: 'Bob Silva'; 'Christian Schneider'; 'PHP internals'
> Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands
> of
Hello Jessie,
yes and no. During 5.0 development i had private and protected inheritance
already and we voted against them. So i think we would vote against private
classes in namespaces as well.
regards
marcus
Monday, November 28, 2005, 9:19:32 PM, you wrote:
> Marcus,
> In my patch, you ca
om: Marcus Boerger [mailto:[EMAIL PROTECTED]
>> Sent: Monday, November 28, 2005 10:15 PM
>> To: Dmitry Stogov
>> Cc: 'Bob Silva'; 'Christian Schneider'; 'PHP internals'
>> Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands
>>
Marcus,
In my patch, you can define the class as "private" inside the namespace, so
it could only be derived by classes inside the same namespace
(using/instantiating outside will trigger an error). This might solve your
problem.
Regards,
Jessie
"Marcus Boerger" <[EMAIL PROTECTED]> wrote in m
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> > Sent: Monday, November 28, 2005 10:15 PM
> > To: Dmitry Stogov
> > Cc: 'Bob Silva'; 'Christian Schneider'; 'PHP internals'
> > Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousan
MB>>If it is not final you could derive the config class and then
MB>>instanciate it. Static classes which nicely fit into configuration
MB>>stuff can never be instanciated.
I see you point, though I don't see any disaster if someone derives and
instantiates config class either.
--
Stanislav M
Hello Stanislav,
Monday, November 28, 2005, 9:10:55 PM, you wrote:
MB>>>'Config' or 'Setup' or alike then. But if i'd do that i'd be missing
MB>>>features like static classes the php workaround would be 'abstract
MB>>>final class'. Only:
> Why should it be final? Extending it won't do any pr
cus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 28, 2005 10:15 PM
> To: Dmitry Stogov
> Cc: 'Bob Silva'; 'Christian Schneider'; 'PHP internals'
> Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands
> of apps out there)
>
>
&
MB>>'Config' or 'Setup' or alike then. But if i'd do that i'd be missing
MB>>features like static classes the php workaround would be 'abstract
MB>>final class'. Only:
Why should it be final? Extending it won't do any problem AFAIU.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTE
BdB>>uses predefined constants and classes that might conflict with other
BdB>>classes and constants in the script.
Just a sec. For now, there's no constants outside of classes AFAIR?
Only define() and class constants. So your library won't refer to any
namespace constants, right? So how namespa
Hello Stanislav,
nothing really. I only think that it is easier to have the consts in
the namespace then in an extra class. I probably would call the class
'Config' or 'Setup' or alike then. But if i'd do that i'd be missing
features like static classes the php workaround would be 'abstract
Hello Stanislav,
even if we wouldn't allow them the users would get conflicts in their
brains sooner or later. On the other hand \ has a clear visible split
meaning. That is all the namespace operator must have besides not
causing any conflict in the parser or human brains.
Btw, during paris me
Namespace constants can be handy if you'd want to include some library
that uses predefined constants and classes that might conflict with
other classes and constants in the script.
namespace someLib {
include('huge_conflicting_library_that_I_dont_want_to_reverse_engineer');
}
Stanislav Ma
Hello Marcus,
"Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello Stanislav,
>
> easy changing of behavior in classes of a namespace by only changing one
> value for instance.
>
> namespace Foo
> {
>const XYZ = 42;
>
>class Bar
>{
> const =
MB>>namespace Foo
MB>>{
class Behaviour {
MB>> const XYZ = 42;
}
MB>> class Bar
MB>> {
MB>> const = Foo::XYZ;
const = Behaviour::XYZ;
MB>> //...
MB>> }
etc. What's wrong with that? Except for the fact that now you can move
these classes to another namespace if you wan
Stas,
I agree that namespace constants are not needed, and are even problematic.
If I import a namespace that is divided among several files and I use a
constant from that namespace, __autoload won't let me find, and I won't know
where it is either. It's better to have a "Config" class under the n
Hello Stanislav,
easy changing of behavior in classes of a namespace by only changing one
value for instance.
namespace Foo
{
const XYZ = 42;
class Bar
{
const = Foo::XYZ;
//...
}
class Baz
{
const = Foo::XYZ;
//...
}
}
marcus
Monday, Novem
MB>>brains sooner or later. On the other hand \ has a clear visible split
MB>>meaning. That is all the namespace operator must have besides not
Yes, except that it is used as escape character in a dozen of languages or
more and automatically recognized as such by any experienced programmer,
who
MB>> your patch wasn't complete. There are conflicts as soon as you have
MB>>subnamespaces or constsants.
You mean namespace contsants? I don't think they are needed. You can
always define utility class for them if you want. As for subnamespaces,
which I think also not necessary anyway, I don't
ry.
>> -Original Message-
>> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
>> Sent: Saturday, November 26, 2005 3:42 PM
>> To: Bob Silva
>> Cc: 'Christian Schneider'; 'PHP internals'
>> Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to br
>
> Bob Silva
>
>
> -Original Message-
> From: Jessie Hernandez [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 28, 2005 8:03 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out
> there)
>
> Dmitry,
ch will ever be accepted if we don't have agreement of
what namespaces should do and not do.
Bob Silva
-Original Message-
From: Jessie Hernandez [mailto:[EMAIL PROTECTED]
Sent: Monday, November 28, 2005 8:03 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How
ks with "::" and doesn't break any scripts.
>
> Dmitry.
>
> > -Original Message-
> > From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, November 26, 2005 3:42 PM
> > To: Bob Silva
> > Cc: 'Christian Schneider'; &#x
3:42 PM
To: Bob Silva
Cc: 'Christian Schneider'; 'PHP internals'
Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands
of apps out there)
Hello Bob,
it is only awkward because you want to turn php into c++.
We are a different language here and thus can chose any
separ
so be it, but I think
> alternatives with
> > some level of compromise should be considered before \ is settled
> > upon. It's just plain awkward IMO.
>
>
> > Bob Silva
>
>
> >> -Original Message-
> >> From: Christian S
Markus Fischer schrieb:
> Kevin Brown wrote:
>
>>The only scripts that would break (far from "trillions") here would be
>>those where you had a space-less ternary statement comparing two
>>constants (NOT namespace constants -- they don't even exist yet), as
>>in the following case:
>>
>>define('fo
mbneto wrote:
> Ilia,
>
> I do not agree with this. Since there should be only bugfixes in RC
> I should only test to see if the known problems are gone and there are
> no regressions. Check if the NEW classe/function clashes with mine's
> or PEAR's not!
Some bug fixes may cause regressions in
Ilia,
I do not agree with this. Since there should be only bugfixes in RC
I should only test to see if the known problems are gone and there are
no regressions. Check if the NEW classe/function clashes with mine's
or PEAR's not!
> > You cannot expect folks to re-test everything with every ne
On Sat, 26 Nov 2005, Ilia Alshanetsky wrote:
I'd prefer ::: over \ for a namespace operator, even though it is
bordering on the "too-long" limit.
Well, how often you think it's used in a script?
If there will be namespaces, I'd prefer ::: too.
--Jani
--
PHP Internals - PHP Runti
Kevin Brown wrote:
The only scripts that would break (far from "trillions") here would be
those where you had a space-less ternary statement comparing two
constants (NOT namespace constants -- they don't even exist yet), as
in the following case:
define('foo','odd');
define('bar','even');
$var =
Matthias Pigulla wrote:
> I have to back Sebastian with what he said. Obviously the release methodology
> currently applied does NOT work, neither for the project nor the community
> around it.
It has worked for many years, just because of one problem you don't
scrap the process.
> BUT: Once yo
D]
> Sent: Saturday, November 26, 2005 1:36 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out
> there)
>
> The only scripts that would break (far from "trillions") here would be
> those where you had a space-less ter
Hello Alan,
Alan Knowles wrote:
this is not entirely true:
token : "[WS]+?[WS]+" == conditional if seperater 1
token : "[WS]+:[WS]+" == conditional if seperater 2
token : ":[WS]+" == case/ if ($a == 5): / else: / endif;
token : ":" == namespace stuff...
eg. adding whitespace around the " : " a
this is not entirely true:
token : "[WS]+?[WS]+" == conditional if seperater 1
token : "[WS]+:[WS]+" == conditional if seperater 2
token : ":[WS]+" == case/ if ($a == 5): / else: / endif;
token : ":" == namespace stuff...
eg. adding whitespace around the " : " and declaring that a token,
rather t
that's all Sebastian pointed out.
-mp.
> -Ursprüngliche Nachricht-
> Von: Ilia Alshanetsky [mailto:[EMAIL PROTECTED]
> Gesendet: Samstag, 26. November 2005 16:49
> An: Sebastian Bergmann
> Cc: internals@lists.php.net
> Betreff: Re: [PHP-DEV] Re: PHP 5.1 (Or How
Hello Kevin,
bla!
Saturday, November 26, 2005, 10:35:51 PM, you wrote:
> The only scripts that would break (far from "trillions") here would be
> those where you had a space-less ternary statement comparing two
> constants (NOT namespace constants -- they don't even exist yet), as
> in the fol
The only scripts that would break (far from "trillions") here would be
those where you had a space-less ternary statement comparing two
constants (NOT namespace constants -- they don't even exist yet), as
in the following case:
define('foo','odd');
define('bar','even');
$var = rand() % 2 == 1 ? fo
Oops, hit "send" too soon! As you saw, ":-" cannot be used, but ":>"
looks like a possibility. Does anyone see anything wrong with this
sequence? Personally, I'd prefer ":::", as ":>" looks weird, but then
again, it's less typing.
I'll put in whatever sequence is most accepted, except of cours
Hi Oliver,
Oliver Grätz wrote:
Ilia Alshanetsky schrieb:
I'd prefer ::: over \ for a namespace operator, even though it is
bordering on the "too-long" limit.
What about these:
PEAR:>Date
PEAR:-Date
OLLi
I thought of these, but it'll break the following examples:
echo ( ( time() % 2
+1 from me. \ looks ugly ... like escaping something:)
On 26/11/05, David Zülke <[EMAIL PROTECTED]> wrote:
> This is funny... I was just about to write a mail and propose ":::".
> So... +1 from me ;)
>
> - David
>
>
> Am 26.11.2005 um 21:10 schrieb Jessie Hernandez:
>
> > All,
> >
> > What would y
Ilia Alshanetsky schrieb:
> I'd prefer ::: over \ for a namespace operator, even though it is
> bordering on the "too-long" limit.
What about these:
PEAR:>Date
PEAR:-Date
OLLi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'd prefer ::: over \ for a namespace operator, even though it is
bordering on the "too-long" limit.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
BTW, "::" is out the question (yes, I did try it). It created ambiguity
in the case of calling a function in a namespace and calling a method of
a class in a namespace:
echo a::b::c();
The above can either mean "call function c in namespace b under
namespace a" or "call static method c of cla
This is funny... I was just about to write a mail and propose ":::".
So... +1 from me ;)
- David
Am 26.11.2005 um 21:10 schrieb Jessie Hernandez:
All,
What would you say if I managed to solve this problem, but that the
solution entailed changing the namespace separator to ":::"? The
co
All,
What would you say if I managed to solve this problem, but that the
solution entailed changing the namespace separator to ":::"? The code
below works fine locally.
Is ":::" unacceptable? Personally, I think anything is better than using
"\", and ":::" is not bad for me. If not, which ch
Jessie Hernandez wrote:
We have two options here:
1) Do not allow constants in namespaces, just stick to functions and
classes.
2) Forget about this inconsistency.
I understand your point of view, but it seems crazy to me to use "\", an
operator that makes absolutely no sense at all and will
Sebastian Bergmann schrieb:
> Marcus Boerger schrieb:
>
>>And i'd say that people wanting namespaces are the minority.
>
>
> The majority of people using PHP does not know what namespaces are
> because they were never in a situation in which they needed them, hence
> they do not "want" them.
Hi Chris,
Christian Schneider wrote:
From Jessie's statements I was assuming that ONLY in the ternary case
you would need whitespaces/parens to disambiguate the expression. That
would break way less PHP scripts than, say, a core Date class ;-)
Yes, this is true, but still, I wouldn't be
Hello Oliver,
Oliver Grätz wrote:
If I read Jessie correctly, the parser will throw an error now if the
usage is unclear with the ternary (a:b:c:d). So the real problem is when
namespace constants are not used but the parser thinks that he's reading
some:
$a = ($b)? c:d;
Are c and d constants
No one project follows the same release methodoly, everyone uses what
works for them and the community around the project.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, 26 Nov 2005, Sebastian Bergmann wrote:
Marcus Boerger schrieb:
And i'd say that people wanting namespaces are the minority.
The majority of people using PHP does not know what namespaces are
because they were never in a situation in which they needed them, hence
they do not "want" th
On Sat, 26 Nov 2005, Sebastian Bergmann wrote:
Jani Taskinen schrieb:
Like the one you just committed couple of days ago? REVERT! :)
I merged the patch in question to the PHP_5_1 branch *after* PHP 5.1.0
had been rolled and *before* the release cycle for PHP 5.1.1 was
started.
Then you
Marcus Boerger schrieb:
> And i'd say that people wanting namespaces are the minority.
The majority of people using PHP does not know what namespaces are
because they were never in a situation in which they needed them, hence
they do not "want" them.
--
Sebastian Bergmann
Jani Taskinen schrieb:
> Like the one you just committed couple of days ago? REVERT! :)
I merged the patch in question to the PHP_5_1 branch *after* PHP 5.1.0
had been rolled and *before* the release cycle for PHP 5.1.1 was
started.
--
Sebastian Bergmann http://www.sebast
Marcus Boerger wrote:
PS: I'd rather have : for namespaces with the whitespace restriction for
? a:x : b:y than the confusing (escaping characters outside of a
string?) backslash.
And kill trillions of php scripts, how funny. Think before writing.
From Jessie's statements I was assuming that
Sebastian Kugler wrote:
Forcing the use of brackets (instead of whitespaces) only for places
where you want to use namespace constants in ternaries is also
impossible?
exactly
--
Hartmut Holzgraefe, Senior Support Engineer.
MySQL AB, www.mysql.com
--
PHP Internals
Marcus Boerger schrieb:
> Hello Oliver,
>
> it doesn't matter to the compiler whether it is nonsense or not.
> The only thing that matters is whether i can write a correct
> lexer/parser for this without breaking stuff. Guys if we were requiring
> space around the ternary or anything else we don
On Sat, 2005-11-26 at 13:38 +0100, Marcus Boerger wrote:
> Hello Christian,
>
> Saturday, November 26, 2005, 1:42:07 AM, you wrote:
> > PS: I'd rather have : for namespaces with the whitespace restriction for
> > ? a:x : b:y than the confusing (escaping characters outside of a
> > string?) backs
Hello Greg,
we previously shipped a lot of pear classes and now we only ship the
installer. Back when we had the pear classes in the main distro i used
to test them even though i didn't use any of them. Right now the only
stuff i test is stuff i really use and that is a single pear class and
tha
Hello Marcus,
On 11/26/05, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> A lexer splits on tokens while white space is optional. If present it
> allows separation of tokens. Forcing this would make whitespace a token
> which would be very bad. The parser then works on the tokens and doesn't
> see an
Hello Joseph,
then why start this discussion over again. Read first, think second. Third
write if there is still a need. Regarding second ever used the '.' operator
in PHP? And you are Zend certified, damn the test is to easy :-)
marcus
Saturday, November 26, 2005, 1:48:35 PM, you wrote:
> wh
Hello Sebastian,
Saturday, November 26, 2005, 1:46:31 PM, you wrote:
> On 11/26/05, Marcus Boerger <[EMAIL PROTECTED]> wrote:
>> The only thing that matters is whether i can write a correct
>> lexer/parser for this without breaking stuff.
> Im no parser expert at all, so just to be sure that I u
Hello Greg,
Saturday, November 26, 2005, 1:20:36 AM, you wrote:
> Marcus Boerger wrote:
>> Hello Helgi,
>>
>> obviously one problem is that PEAR does ignore coding standards. Classes
>> should be prefixed in both pear and core. And neither Date nor File is in
>> any way prefixed. In th end all
what are the options for the seperator? i have not been watching this topic
but is the . out of the question?
namespace.class->method();
--
Joseph Crawford Jr.
Zend Certified Engineer
Codebowl Solutions, Inc.
1-802-671-2021
[EMAIL PROTECTED]
On Sat, 26 Nov 2005, Sebastian Bergmann wrote:
I think we should finally stop to commit non-bugfix changes to a release
Like the one you just committed couple of days ago? REVERT! :)
--Jani
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
On 11/26/05, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> The only thing that matters is whether i can write a correct
> lexer/parser for this without breaking stuff.
Im no parser expert at all, so just to be sure that I understand the
problem correctly: I guess you can't distinguish at the parser/
Hello Gareth,
Saturday, November 26, 2005, 2:22:15 AM, you wrote:
> Jessie Hernandez wrote:
>> Hi Chris,
>>
>> Christian Schneider wrote:
>>
>>>
>>> PS: I'd rather have : for namespaces with the whitespace restriction
>>> for ? a:x : b:y than the confusing (escaping characters outside of a
>>
PROTECTED]
>> Sent: Friday, November 25, 2005 4:42 PM
>> To: Marcus Boerger
>> Cc: PHP internals
>> Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out
>> there)
>>
>> Marcus Boerger wrote:
>> > here again namespaces
Hello Christian,
Saturday, November 26, 2005, 1:42:07 AM, you wrote:
> Marcus Boerger wrote:
>> here again namespaces would be perfect. Given a lib that doesn't prefix
>> you'd simply do:
>> namespace LibNameHere { reqire "some_lib_include"; }
>> and be done...wohooo :-)
> Only if newly introd
Hello Martin,
the funny thing here is that obviously we cannot prefix things we have
right now. Using namepsaces we would be free to enforce namespaces upon
everyhting that's been built in and simply provide import. And if we
really wanted to we could also have a "zend.ze1_compatibility_mode" li
Hello Oliver,
it doesn't matter to the compiler whether it is nonsense or not.
The only thing that matters is whether i can write a correct
lexer/parser for this without breaking stuff. Guys if we were requiring
space around the ternary or anything else we don't do right now then
the damage is m
On Saturday 26 November 2005 00:36, Rasmus Lerdorf wrote:
> I must be missing something. How is switch whitespace sensitive?
http://bugs.php.net/bug.php?id=25667
Perhaps you will consider this different.
Even so, PHP is pretty much inconsistant all over the place, I don't think
having to put s
Marcus Boerger wrote:
here again namespaces would be perfect. Given a lib that doesn't prefix
you'd simply do:
namespace LibNameHere { reqire "some_lib_include"; }
and be done...wohooo :-)
Only if newly introduced PHP core classes use a namespace too. You'll have
to use PHP\Date (or the like
Rasmus Lerdorf schrieb:
> I know it wasn't an intentional thing, but Derick's view that "Gotcha!
> It's in 5.1.0 now, so you can't change it" doesn't sit well with me
Whether or not Derick did this intentionally and/or for selfish reasons
I cannot say (but I do not think so, since it would be un
On Sat Nov 26, 2005 at 09:5522AM +0100, Ron Korving wrote:
> > Speaking of this, I like Greg's suggestion about prefixing all internal
> > classes with PHP_. While there are certainly classes out there that are
> > prefixed with it, we could tell developers that starting with e.g. PHP 6
> > the PH
> Speaking of this, I like Greg's suggestion about prefixing all internal
> classes with PHP_. While there are certainly classes out there that are
> prefixed with it, we could tell developers that starting with e.g. PHP 6
> the PHP_* class scope is reserved for the language core and must not be
>
"Jessie Hernandez" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Bob Silva wrote:
> >>$x = $y ? foo:bar:baz:stupid;
> >
> >
> > I think "stupid" is the key word here, by forcing the whitespace or (),
you
> > are making the language itself stupid by not knowing how to parse
itself.
On Fri Nov 25, 2005 at 09:1028PM +0100, Marcus Boerger wrote:
> i think you didn't understand the whole point here. Naming something
> after an every day word just like 'Date' is like screaming for problems in
> bigger scenarios. It is a beginners mistake to not prefix such stuff.
Assuming this
Sorry for the double posts, Thunderbird's been acting weird lately...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Greg Beaver wrote:
Jessie Hernandez wrote:
1) Do not allow constants in namespaces, just stick to functions and
classes.
I am confused as to why we need namespaced constants. Now that we have
class constants, this is a far better way to "namespace" constants. I
was also under the impressio
Greg Beaver wrote:
Jessie Hernandez wrote:
1) Do not allow constants in namespaces, just stick to functions and
classes.
I am confused as to why we need namespaced constants. Now that we have
class constants, this is a far better way to "namespace" constants. I
was also under the impressio
Marcus Boerger wrote:
> Hello Guys,
>
> simply because the crew that actually develops php and tests it a lot
> before a release obviously doesn't use PEAR. And given the fact that pear
> was dropped from the main releases because it didn't fit into it
> functionality and compatibility wise anyw
Jessie Hernandez wrote:
> 1) Do not allow constants in namespaces, just stick to functions and
> classes.
I am confused as to why we need namespaced constants. Now that we have
class constants, this is a far better way to "namespace" constants. I
was also under the impression that this was far m
Bob Silva wrote:
$x = $y ? foo:bar:baz:stupid;
I think "stupid" is the key word here, by forcing the whitespace or (), you
are making the language itself stupid by not knowing how to parse itself.
I'm not a core developer, but I am pretty sure that this implementation will
never be accepted, s
z [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 25, 2005 8:37 PM
> To: internals@lists.php.net; Oliver Grätz
> Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out
> there)
>
> Hello Oliver,
>
> Oliver Grätz wrote:
> > Marcus Boerger schrie
Hi Oliver,
Oliver Grätz wrote:
So if one only allows simple namespaces (no nesting), then one can see
that this need to be two namespace constants BUT one has to read the
whole line:
- one colon means simple constants
- three colons: two namespaces constants
- two colons: ERROR, undefined
If
Oliver Grätz schrieb:
> PS: How about a unicode symbol (egypt god Ra) as namespace operator.
> PHP6 will be all about unicode => Yeah, gazillions of new operator
> symbols. Or register a "PHP namespace separator symbol" that looks like
> the PHP logo. Just kidding...
Responding to myself: Why is
1 - 100 of 273 matches
Mail list logo
