> 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
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
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
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 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
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
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
>
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
Derick,
I am not sure where you came up with this idea, but it's patently
untrue. Core and userland have to co-exist, and that means cooperation,
not blatant disregard for thousands of users out there. Unless you're
speaking only for yourself, and in that case, I hope your upcoming
vacation i
Hello Matthias,
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.
And if you weren't in a big project - well then simply rename your
Derick Rethans wrote:
> On Fri, 25 Nov 2005, Christian Schneider wrote:
>
>
>>Just to illustrate some question which could be raised to weaken your point
>>that Date is the one and only name for that class:
>>Why does it include time as well, shouldn't it be Datetime (a la SQL)? Is it
>>going to
On Fri, 25 Nov 2005, Christian Schneider wrote:
> Just to illustrate some question which could be raised to weaken your point
> that Date is the one and only name for that class:
> Why does it include time as well, shouldn't it be Datetime (a la SQL)? Is it
> going to be the only class in ext/date
On Fri, 25 Nov 2005, Matthias Pigulla wrote:
>
> > I didn't say that my code is more important, but if we don't
> > get the date class now, we will get it in 5.1.1 and then
> > break your code - so that doesn't really matter. THe only
> > correct solution is to start prefixing the pear date cl
Derick Rethans wrote:
I didn't say that my code is more important, but if we don't get the
date class now, we will get it in 5.1.1 and then break your code - so
You're stating this like a fact. Date _can_ be renamed, there's nothing
sacro-sanct about this class.
Just to illustrate some ques
Derick Rethans wrote:
Using generic names for core functionality in the global name space
is a bad
thing, no matter how convenient the name might be. That's a lesson
PHP has
learned for function names quite a while ago, let's not repeat the same
mistake for class names.
No no, the core r
> I didn't say that my code is more important, but if we don't
> get the date class now, we will get it in 5.1.1 and then
> break your code - so that doesn't really matter. THe only
> correct solution is to start prefixing the pear date class,
> as that needs to be done in the long run anyway.
On Fri, 25 Nov 2005, Matthias Pigulla wrote:
>
> > Yes, and that will break code again as I just explained to
> > Sebastian Kettler. And it will break *my* code ;-)
>
> Too bad I don't find the right mail to qoute you now literally - but
> nobody forces you to use the official PHP codebase for
On Fri, 25 Nov 2005, Christian Schneider wrote:
> Does that mean your code is more important than all the lines of code
> out there? You must be kidding. And as you stated yourself your code
> hasn't even been released yet.
I didn't say that my code is more important, but if we don't get the
d
Derick Rethans wrote:
On Fri, 25 Nov 2005, Sascha Schumann wrote:
I move that the class is renamed for the time being as to not
conflict with existing codebases, and release 5.1.1
expediently.
I second that. Otherwise 5.1 is a dead branch lots of people won't
update to.
Yes, and
> Yes, and that will break code again as I just explained to
> Sebastian Kettler. And it will break *my* code ;-)
Too bad I don't find the right mail to qoute you now literally - but
nobody forces you to use the official PHP codebase for your stuff; go
ahead and maintain releases for yourself.
>
> Then I have to ask both of you: why is there no mentioning in
> the release notes or the upgrading guide regarding "Date"
> being reserved for PHP now?
I was also curious as to that. Once again the release announcement (more
precisely, the "upgrade" document) greatly understate
23 matches
Mail list logo
