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.
Derick, this is not only about the PEAR date class but about pretty much
every larger PHP codebase/project. You don't seem to understand the
impact.
No no, the core reserves the right to name whatever they
want, it's the userland code that is responsible for
prefixing their classes.
Actually I just decided to work through my 100,000 lines of code and
rename every class; for the sake of forwards compatibility, I'll
generate GUIDs for each class and keep a mapping table on my desktop.
Oh, and while I'm at it, I'll switch over to some other language as
well.
-mp.
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.Derick, this is not only about the PEAR date class but about pretty much
every larger PHP codebase/project. You don't seem to understand the
impact.
Yes, I do see that. Read my other mails again. (afaik one to Sascha)
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
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 few
hundred lines of code. Use some nice tools like Ultraedit since your a
windows user the renaming is only a few clicks a way.
marcus
Friday, November 25, 2005, 12:39:45 PM, you 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 class,
as that needs to be done in the long run anyway.
Derick, this is not only about the PEAR date class but about pretty much
every larger PHP codebase/project. You don't seem to understand the
impact.
No no, the core reserves the right to name whatever they
want, it's the userland code that is responsible for
prefixing their classes.
Actually I just decided to work through my 100,000 lines of code and
rename every class; for the sake of forwards compatibility, I'll
generate GUIDs for each class and keep a mapping table on my desktop.
Oh, and while I'm at it, I'll switch over to some other language as
well.
-mp.
--
Best regards,
Marcus
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 is correct, then not only userland code should use proper
prefixes, but also the PHP language core should do so, no?
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
used for any other purpose.
- Martin
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
used for any other purpose.
- Martin
Why would you, if you have namespaces?
Ron
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
used for any other purpose.Why would you, if you have namespaces?
Correct me if I'm wrong, but I got the impression that despite Jessie's
patch and Marcus' competence in all things C people are still unsure if
namespaces will make it into PHP 6. Thus having an alternative strategy
at hand seems wise.
Best,
- Martin
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" like
ini setting to import anything to the global space and voila - the php 6
code writers can go without and those who want to use php 5 stuff can
easily do so. There won't be aproblem for namespaces users when imporint
things to the global space.
marcus
Saturday, November 26, 2005, 10:12:56 AM, you 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 PHP_* class scope is reserved for the language core and must not be
used for any other purpose.Why would you, if you have namespaces?
Correct me if I'm wrong, but I got the impression that despite Jessie's
patch and Marcus' competence in all things C people are still unsure if
namespaces will make it into PHP 6. Thus having an alternative strategy
at hand seems wise.
Best,
- Martin
Best regards,
Marcus