Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early warning for reserved words that will be in future php releases.
regards,
Lukas
Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early warning for reserved words that will be in future php releases.
No future reserved word will contain a capital letter (unless it is entirely caps - constant).
So: nice simple rule - include a capital letter in all your variable/function/... names.
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early warning for reserved words that will be in future php releases.No future reserved word will contain a capital letter (unless it is entirely caps - constant).
Where did you get that idea?
So: nice simple rule - include a capital letter in all your variable/function/...
functions, classnames and methods.... are case-insensitive. Only
variables are case-sensitive.
-Hannes
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early warning for reserved words that will be in future php releases.No future reserved word will contain a capital letter (unless it is
entirely caps - constant).
So: nice simple rule - include a capital letter in all your
variable/function/... names.
And make sure that it is not Latin capital letter i.
PHP bug 18556
Some parts of interpreter are still locale aware in case insensitive
comparison. Test by mike dot ditum still works in php5.2-200708151230 and
6.0-200708151230.
--
Tomas
Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early warning for reserved words that will be in future php releases.
Meaning somewhere like http://php.net/reserved ? :)
-Hannes
Hannes Magnusson wrote:
Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early warning for reserved words that will be in future php releases.Meaning somewhere like http://php.net/reserved ? :)
I mean we should frequently mention it. Hmm maybe what we need is a
forward compatibility newsletter instead. Just something that summarizes
the last 4 weeks worth of BC breaks :)
Guess this can/should then however be semi independent of php.net. I
will ponder if I have the motivation to do this. People helping would be
an encouragement :)
regards,
Lukas
Hello Lukas,
this is a no issue. Prefix your code and be done!
marcus
Wednesday, August 15, 2007, 3:37:20 PM, you wrote:
Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early warning for reserved words that will be in future php releases.
regards,
Lukas
Best regards,
Marcus
In that specific case, a method called import() was in cause (of course,
conflicting with the namespace/package/whatever package). Do you propose
prefixing all method names ?
Hello Lukas,
this is a no issue. Prefix your code and be done!
marcus
Wednesday, August 15, 2007, 3:37:20 PM, you wrote:
Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early warning for reserved words that will be in future php releases.regards,
LukasBest regards,
Marcus--
--
Nicolas Bérard-Nault (nicobn@gmail.com)
Étudiant D.E.C. Sciences, Lettres & Arts
Cégep de Sherbrooke
Homepage: http://nicobn.googlepages.com
Hello Nicolas,
yes. All my global functions and my classes are prefixed.
marcus
Thursday, August 16, 2007, 10:37:30 PM, you wrote:
In that specific case, a method called import() was in cause (of course,
conflicting with the namespace/package/whatever package). Do you propose
prefixing all method names ?
Hello Lukas,
this is a no issue. Prefix your code and be done!
marcus
Wednesday, August 15, 2007, 3:37:20 PM, you wrote:
Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early warning for reserved words that will be in future php releases.regards,
LukasBest regards,
Marcus--
Best regards,
Marcus
I wasn't talking about global functions and classes, I was talking about
class methods. David pretty much sums this up in his email.
Hello Nicolas,
yes. All my global functions and my classes are prefixed.
marcus
Thursday, August 16, 2007, 10:37:30 PM, you wrote:
In that specific case, a method called import() was in cause (of course,
conflicting with the namespace/package/whatever package). Do you propose
prefixing all method names ?Hello Lukas,
this is a no issue. Prefix your code and be done!
marcus
Wednesday, August 15, 2007, 3:37:20 PM, you wrote:
Hi,
Someone in the Doctrine channel just brought up the issue of having
to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.netwith
early warning for reserved words that will be in future php releases.regards,
LukasBest regards,
Marcus--
Best regards,
Marcus
--
Nicolas Bérard-Nault (nicobn@gmail.com)
Étudiant D.E.C. Sciences, Lettres & Arts
Cégep de Sherbrooke
Homepage: http://nicobn.googlepages.com
Hello Nicolas,
yes. All my global functions and my classes are prefixed.
Prefix the methods are not a solution.
The only cases where it is acceptable are the magic methods (when we
introduce new ones) like __get/set. But that happens rarely.
--Pierre
Hello Lukas,
this is a no issue. Prefix your code and be done!
That means prefixing your methods as well ?
The problem is when one calls something like a method "import()"
You prefix your functions ? I think this is silly. Prefix the class to
make it namespace** like, but not the methods...
PEAR_ClassName {
public static function __PEAR_construct() { }
public static function PEAR_import() { }
public static function PEAR_export() { }
}
Which ends in
PEAR_ClassName::PEAR_Import();
Whereas:
PEAR_ClassName::import(); would usually be ok to do.
Prefixing the methods imho is the no go in this case.
marcus
Wednesday, August 15, 2007, 3:37:20 PM, you wrote:
Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early warning for reserved words that will be in future php releases.regards,
LukasBest regards,
Marcus--
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
Hey David & Lucas,
I brought this up a year ago on the list here:
http://marc.info/?t=114728193700003&r=1&w=2
Essentially, the trend will continue to be that as keyword requiring
features are added, the global naming space will continue to become
smaller and less safe for older applications written for older versions
of php.
Until it becomes a goal of php-internals to add contextual awareness and
sensitivity to the compiler's tokenizer, this will always be a problem.
Here is a more amusing list of method names that will also not work:
http://marc.info/?l=php-dev&m=114736739115429&w=2
And the general opinion summed up by Wez ;)
http://marc.info/?l=php-dev&m=114764099400409&w=2
-ralph
David Coallier wrote:
Hello Lukas,
this is a no issue. Prefix your code and be done!
That means prefixing your methods as well ?
The problem is when one calls something like a method "import()"
You prefix your functions ? I think this is silly. Prefix the class to
make it namespace** like, but not the methods...PEAR_ClassName {
public static function __PEAR_construct() { }
public static function PEAR_import() { }
public static function PEAR_export() { }
}Which ends in
PEAR_ClassName::PEAR_Import();
Whereas:
PEAR_ClassName::import(); would usually be ok to do.
Prefixing the methods imho is the no go in this case.
marcus
Wednesday, August 15, 2007, 3:37:20 PM, you wrote:
Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early warning for reserved words that will be in future php releases.
regards,
LukasBest regards,
Marcus
Ralph Schindler wrote:
Hey David & Lucas,
I brought this up a year ago on the list here:http://marc.info/?t=114728193700003&r=1&w=2
Essentially, the trend will continue to be that as keyword requiring
features are added, the global naming space will continue to become
smaller and less safe for older applications written for older versions
of php.Until it becomes a goal of php-internals to add contextual awareness and
sensitivity to the compiler's tokenizer, this will always be a problem.Here is a more amusing list of method names that will also not work:
http://marc.info/?l=php-dev&m=114736739115429&w=2And the general opinion summed up by Wez ;)
Hi,
Doing this with flex is non-trivial. It's a lot easier with a
re2c-based lexer, but porting the flex scanner to re2c is the definition
of "oh-my-god-almighty" complex and until someone just does it, it ain't
gonna happen.
The other hackish alternative is to add rules to the parser with
reserved words (T_FUNCTION T_IMPORT as well as T_FUNCTION T_STRING, etc.
etc.), but this slows down the parser and adds unnecessary duplication.
Greg
Hello Gregory,
the good news on this fron is that re2c meanwhile has a new beta version
with flex like conditoin support. Also when changing from flex to re2c we
should switch from bison to lemon. All in all a damn huge amount of work.
But the result would be much cleaner, faster, more flexible, fully
reentrant, reuseable outside of the engine and cabable of unicode....
Yet you mentioned the big issue, someone would need to do this. Though the
biggest entry on the to do would be discussing it ... hopefully not needting
to rename something
marcus
Friday, August 17, 2007, 7:35:43 PM, you wrote:
Ralph Schindler wrote:
Hey David & Lucas,
I brought this up a year ago on the list here:http://marc.info/?t=114728193700003&r=1&w=2
Essentially, the trend will continue to be that as keyword requiring
features are added, the global naming space will continue to become
smaller and less safe for older applications written for older versions
of php.Until it becomes a goal of php-internals to add contextual awareness and
sensitivity to the compiler's tokenizer, this will always be a problem.Here is a more amusing list of method names that will also not work:
http://marc.info/?l=php-dev&m=114736739115429&w=2And the general opinion summed up by Wez ;)
Hi,
Doing this with flex is non-trivial. It's a lot easier with a
re2c-based lexer, but porting the flex scanner to re2c is the definition
of "oh-my-god-almighty" complex and until someone just does it, it ain't
gonna happen.
The other hackish alternative is to add rules to the parser with
reserved words (T_FUNCTION T_IMPORT as well asT_FUNCTIONT_STRING, etc.
etc.), but this slows down the parser and adds unnecessary duplication.
Greg
Best regards,
Marcus
I think we should rename flex to something else because you just
confused me with that new Adobe not-quite-flash flex thingie...
:-) :-) ;-)
Just Kidding!!!
(Not about the confusing me part, as we all know that's trivial...)
Hello Gregory,
the good news on this fron is that re2c meanwhile has a new beta
version
with flex like conditoin support. Also when changing from flex to re2c
we
should switch from bison to lemon. All in all a damn huge amount of
work.
But the result would be much cleaner, faster, more flexible, fully
reentrant, reuseable outside of the engine and cabable of unicode....
Yet you mentioned the big issue, someone would need to do this. Though
the
biggest entry on the to do would be discussing it ... hopefully not
needting
to rename somethingmarcus
Friday, August 17, 2007, 7:35:43 PM, you wrote:
Ralph Schindler wrote:
Hey David & Lucas,
I brought this up a year ago on the list here:http://marc.info/?t=114728193700003&r=1&w=2
Essentially, the trend will continue to be that as keyword
requiring
features are added, the global naming space will continue to become
smaller and less safe for older applications written for older
versions
of php.Until it becomes a goal of php-internals to add contextual
awareness and
sensitivity to the compiler's tokenizer, this will always be a
problem.Here is a more amusing list of method names that will also not
work:
http://marc.info/?l=php-dev&m=114736739115429&w=2And the general opinion summed up by Wez ;)
Hi,
Doing this with flex is non-trivial. It's a lot easier with a
re2c-based lexer, but porting the flex scanner to re2c is the
definition
of "oh-my-god-almighty" complex and until someone just does it, it
ain't
gonna happen.The other hackish alternative is to add rules to the parser with
reserved words (T_FUNCTION T_IMPORT as well asT_FUNCTIONT_STRING,
etc.
etc.), but this slows down the parser and adds unnecessary
duplication.Greg
Best regards,
Marcus--
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?