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 ? foo:bar;
It seems like the solution here would be to give constants a higher
priority in the symbol table than namespaces, though I certainly don't
have the knowledge of the code base to make any conclusion as to how
difficult that might be.
Personally, I'd rather have namespaces with stupid symbols than no
namespaces, but my preference would definitely be either single or
double colons, as would most users, I wager, since that's probably the
most common namespace symbol in use amongst popular languages that
support namespaces. The argument that PHP isn't <insert language>
sounds good on paper, but in practice the language still has to
conform to some basic expectations when it comes to syntax. There's a
reason why the -> operator was chosen for member access, there's a
reason why || and && are used for logic operators, there's a reason
why the dollar sign is used to declare variables, and there's a reason
why a semicolon is used to end statements. NS:Class vs NS::Class vs
NS\Class is largely insignificant at the end of the day, but it's
better to try to stick to some common symbols that programmers of
different disciplines will be able to pick up on. PHP isn't taught in
most universities, and making things even harder for people to pick it
up seems counter-intuitive.
People who's "php coding" is limited to editing config files for
vbulletin and xcart certainly couldn't care less about namespaces, but
those of us who are writing applications and middleware, as well as
complex sites, would find the functionality tremendously useful. I'm
tired of walking on glass worrying about naming conflicts.
It's easy to say "well, name your classes sensibly!", but the reality
is that it's totally non-sensical to ask a developer to prefix THEIR
classes in application code. We're not psychics, we can't guess that
one day some core developer is going to create a Date class that will
cause fatal errors in our code. It's not just Date, of course -- it's
every common name out there. Should I not name a class
FrontController, because the SPL might implement one later? The list
goes on and on. The only real solution is to use NON-sensible class
names (I prefer greek dieties) to guarantee future-proofness.
Virtually every major application out there, from vbulletin to
MediaWiki to phpAdsNew has had a major naming conflict with another
application. Having silly dangly things on every classname / function
name gets annoying (at best), and is a giant waste of time. We want
short, concise function and class names, not
"my_application_html_clean_sessions()" Being able to import a
namespace that you need with aliases (or even just into the global
namespace) is a HUGE plus. This is especially true since PHP itself
doesn't even really follow a naming convention (htmlentities vs
html_entity_decode, isset vs. is_int and so on and so forth). If the
core doesn't follow conventions, how can you expect userland code to?
Even if the namespace patch is something that has to be done as an
extension, I'd be happy to see it in place. It's a fairly easy task to
get users to add --with-namespaces to their configure scripts, but
it's much more difficult to ask them to try to use diff and patch to
maintain their own builds (much less hand-edit C code).
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 following case:
define('foo','odd');
define('bar','even');
$var =rand()% 2 == 1 ? foo:bar;
It seems like the solution here would be to give constants a higher
priority in the symbol table than namespaces, though I certainly don't
have the knowledge of the code base to make any conclusion as to how
difficult that might be.
Personally, I'd rather have namespaces with stupid symbols than no
namespaces, but my preference would definitely be either single or
double colons, as would most users, I wager, since that's probably the
most common namespace symbol in use amongst popular languages that
support namespaces. The argument that PHP isn't <insert language>
sounds good on paper, but in practice the language still has to
conform to some basic expectations when it comes to syntax. There's a
reason why the -> operator was chosen for member access, there's a
reason why || and && are used for logic operators, there's a reason
why the dollar sign is used to declare variables, and there's a reason
why a semicolon is used to end statements. NS:Class vs NS::Class vs
NS\Class is largely insignificant at the end of the day, but it's
better to try to stick to some common symbols that programmers of
different disciplines will be able to pick up on. PHP isn't taught in
most universities, and making things even harder for people to pick it
up seems counter-intuitive.
People who's "php coding" is limited to editing config files for
vbulletin and xcart certainly couldn't care less about namespaces, but
those of us who are writing applications and middleware, as well as
complex sites, would find the functionality tremendously useful. I'm
tired of walking on glass worrying about naming conflicts.
It's easy to say "well, name your classes sensibly!", but the reality
is that it's totally non-sensical to ask a developer to prefix THEIR
classes in application code. We're not psychics, we can't guess that
one day some core developer is going to create a Date class that will
cause fatal errors in our code. It's not just Date, of course -- it's
every common name out there. Should I not name a class
FrontController, because the SPL might implement one later? The list
goes on and on. The only real solution is to use NON-sensible class
names (I prefer greek dieties) to guarantee future-proofness.
Virtually every major application out there, from vbulletin to
MediaWiki to phpAdsNew has had a major naming conflict with another
application. Having silly dangly things on every classname / function
name gets annoying (at best), and is a giant waste of time. We want
short, concise function and class names, not
"my_application_html_clean_sessions()" Being able to import a
namespace that you need with aliases (or even just into the global
namespace) is a HUGE plus. This is especially true since PHP itself
doesn't even really follow a naming convention (htmlentities vs
html_entity_decode, isset vs. is_int and so on and so forth). If the
core doesn't follow conventions, how can you expect userland code to?
Even if the namespace patch is something that has to be done as an
extension, I'd be happy to see it in place. It's a fairly easy task to
get users to add --with-namespaces to their configure scripts, but
it's much more difficult to ask them to try to use diff and patch to
maintain their own builds (much less hand-edit C code).
--
Best regards,
Marcus
Very good points Kevin since I was accused of wanting to turn PHP into C++
earlier just for not liking the \ separator. I suppose the person that
selected the -> object operator had the same intentions :)
Bob
-----Original Message-----
From: Kevin Brown [mailto:etnu00@gmail.com]
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 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 ? foo:bar;It seems like the solution here would be to give constants a higher
priority in the symbol table than namespaces, though I certainly don't
have the knowledge of the code base to make any conclusion as to how
difficult that might be.Personally, I'd rather have namespaces with stupid symbols than no
namespaces, but my preference would definitely be either single or
double colons, as would most users, I wager, since that's probably the
most common namespace symbol in use amongst popular languages that
support namespaces. The argument that PHP isn't <insert language>
sounds good on paper, but in practice the language still has to
conform to some basic expectations when it comes to syntax. There's a
reason why the -> operator was chosen for member access, there's a
reason why || and && are used for logic operators, there's a reason
why the dollar sign is used to declare variables, and there's a reason
why a semicolon is used to end statements. NS:Class vs NS::Class vs
NS\Class is largely insignificant at the end of the day, but it's
better to try to stick to some common symbols that programmers of
different disciplines will be able to pick up on. PHP isn't taught in
most universities, and making things even harder for people to pick it
up seems counter-intuitive.People who's "php coding" is limited to editing config files for
vbulletin and xcart certainly couldn't care less about namespaces, but
those of us who are writing applications and middleware, as well as
complex sites, would find the functionality tremendously useful. I'm
tired of walking on glass worrying about naming conflicts.It's easy to say "well, name your classes sensibly!", but the reality
is that it's totally non-sensical to ask a developer to prefix THEIR
classes in application code. We're not psychics, we can't guess that
one day some core developer is going to create a Date class that will
cause fatal errors in our code. It's not just Date, of course -- it's
every common name out there. Should I not name a class
FrontController, because the SPL might implement one later? The list
goes on and on. The only real solution is to use NON-sensible class
names (I prefer greek dieties) to guarantee future-proofness.
Virtually every major application out there, from vbulletin to
MediaWiki to phpAdsNew has had a major naming conflict with another
application. Having silly dangly things on every classname / function
name gets annoying (at best), and is a giant waste of time. We want
short, concise function and class names, not
"my_application_html_clean_sessions()" Being able to import a
namespace that you need with aliases (or even just into the global
namespace) is a HUGE plus. This is especially true since PHP itself
doesn't even really follow a naming convention (htmlentities vs
html_entity_decode, isset vs. is_int and so on and so forth). If the
core doesn't follow conventions, how can you expect userland code to?Even if the namespace patch is something that has to be done as an
extension, I'd be happy to see it in place. It's a fairly easy task to
get users to add --with-namespaces to their configure scripts, but
it's much more difficult to ask them to try to use diff and patch to
maintain their own builds (much less hand-edit C code).
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 =rand()% 2 == 1 ? foo:bar;
Do we have a way getting numbers on how high the probability is that
someone is using two constants in the ternary operator without spaces?
Would "major PHP open source" projects count? Probably not, because
they don't represent the majority of ordinary PHP users.
I mean, comparing this to the current problem with the new date class,
it seems that it is much more unlikely that this is out there (but it
will be, definitely, and it will affect "some" users, definitely) then a
date class, that even from my users point of view ("upgrading php is
almost always pain because of BC problems") I would go for Jessies
implementation.
sincerly,
- Markus
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('foo','odd');
define('bar','even');
$var =rand()% 2 == 1 ? foo:bar;Do we have a way getting numbers on how high the probability is that
someone is using two constants in the ternary operator without spaces?
How exactly is this a big problem? Is the parser always working from
left to right and assigning a token on current context or is it looking
at the whole line? Is it impossible to give the ternary operator a
higher priority than the namespace operator?
Then the implementation could always treat foo:bar as being two
constants in the ternary. This way only new code not using whitespace
would throw parsing errors which actually means that NO existing code
breaks.
OLLi