The Problem (as defined by Greg):
foo.php:
<?php
namespace one::step;
function two(){}
namespace one;
class step {
static function two(){}
}
?>
main.php:
<?php
include 'foo.php';
// is this class one::step or namespace one::step?
one::step::two();
?>
A Simpler Solution
Force userland / general naming conventions in PHP.
namespaces are always lowercase
functions are always lowercase
classes are always CamelCaps with initial uppercase letter enforced
thus:
//this is always the function two in namespace one::step
one::step::two();
//this is always the method two of class step in namespace one
one::Step::two();
thoughts, opinions, reasons why it wouldn't work?
regards,
nathan
Nathan Rixham wrote:
thus:
//this is always the function two in namespace one::step
one::step::two();
//this is always the method two of class step in namespace one
one::Step::two();thoughts, opinions, reasons why it wouldn't work?
Though: this will break a awful lot of existing code
Opinion: bad idea
Ron
regards,
nathan
thoughts, opinions, reasons why it wouldn't work?
Posts like this want me to shutdown this list, start a new one, hide it,
and make it invite only.
Derick
--
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
AFAIK the classes and the namespaces both are case insensitive. This means a
major change (to make them to be kept in a sensitive way) and will break the
code that depends on the insensibility.
IMHO - bad idea.
And besides the casing usially is used to enforce good coding practices, not
language features.
The Problem (as defined by Greg):
foo.php:
<?php
namespace one::step;
function two(){}namespace one;
class step {
static function two(){}
}
?>main.php:
<?php
include 'foo.php';
// is this class one::step or namespace one::step?
one::step::two();
?>A Simpler Solution
Force userland / general naming conventions in PHP.namespaces are always lowercase
functions are always lowercase
classes are always CamelCaps with initial uppercase letter enforced
thus:
//this is always the function two in namespace one::step
one::step::two();
//this is always the method two of class step in namespace one
one::Step::two();thoughts, opinions, reasons why it wouldn't work?
regards,
nathan
--
--
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com
A Simpler Solution
Force userland / general naming conventions in PHP.namespaces are always lowercase
functions are always lowercase
classes are always CamelCaps with initial uppercase letter enforced
thus:
//this is always the function two in namespace one::step
one::step::two();
//this is always the method two of class step in namespace one
one::Step::two();thoughts, opinions, reasons why it wouldn't work?
Assuming this is a real question:
-
PHP is heading towards broad i18n. How do you "uppercase" or
"lowercase" written languages that don't have a concept of case? -
PHP was designed for wide adoption, and the authors of libraries
often used function and class cases that matched their library. So,
PHP case smashes, to Handle the problem of pg_pconnect (all smashed),
PG_pConnect (EXTENSION_argumentAction), Pg_Pconnect (first letter
ucase), etc. etc. etc.
Right now this all works. Changing it would break, well, darned near
everything. -
The vast majority of user operating systems (and filesystems) out
there do NOT, I repeat, do NOT all handle case in the same way, a
sane way. Windows boxes are still lugging around DOS/VMS legacy with
UPPERCAS.$1 files, Macs have their own breed of jollies as well, and
anything that autoloads (such as namespace code) needs to handle all
of these.
Assuming that this is "A Modest Proposal":
- It needs to be more over the top to be funny to a broad, multi-
lingual, global, audience.
For example, you might have suggested that we add an include_instead
() operator, so somebody who wants to use a function/method which is
located in '/var/location1/file_class.inc', rather than the already
loaded function/method in '/var/location2/file_functions.inc', can
override an existing function/method, and for giggles, you might
suggest that the operator have the power to override all internal
functions, but just for local execution scope, spawning a new process/
thread for each invocation, so a blog post can have 30-80 thousand
processes with different scopes.... to render a web page.
Okay, I'm shutting up now. :)
-Bop
Ronald Chmara wrote:
A Simpler Solution
Force userland / general naming conventions in PHP.namespaces are always lowercase
functions are always lowercase
classes are always CamelCaps with initial uppercase letter enforced
thus:
//this is always the function two in namespace one::step
one::step::two();
//this is always the method two of class step in namespace one
one::Step::two();thoughts, opinions, reasons why it wouldn't work?
Assuming this is a real question:
PHP is heading towards broad i18n. How do you "uppercase" or
"lowercase" written languages that don't have a concept of case?PHP was designed for wide adoption, and the authors of libraries
often used function and class cases that matched their library. So,
PHP case smashes, to Handle the problem of pg_pconnect (all smashed),
PG_pConnect (EXTENSION_argumentAction), Pg_Pconnect (first letter
ucase), etc. etc. etc.
Right now this all works. Changing it would break, well, darned near
everything.The vast majority of user operating systems (and filesystems) out
there do NOT, I repeat, do NOT all handle case in the same way, a
sane way. Windows boxes are still lugging around DOS/VMS legacy with
UPPERCAS.$1 files, Macs have their own breed of jollies as well, and
anything that autoloads (such as namespace code) needs to handle all
of these.Assuming that this is "A Modest Proposal":
- It needs to be more over the top to be funny to a broad,
multi-lingual, global, audience.For example, you might have suggested that we add an include_instead()
operator, so somebody who wants to use a function/method which is
located in '/var/location1/file_class.inc', rather than the already
loaded function/method in '/var/location2/file_functions.inc', can
override an existing function/method, and for giggles, you might
suggest that the operator have the power to override all internal
functions, but just for local execution scope, spawning a new
process/thread for each invocation, so a blog post can have 30-80
thousand processes with different scopes.... to render a web page.Okay, I'm shutting up now. :)
-Bop
Thanks Bop,
After more thought I came to pretty much the same thoughts - received
some heavy replies but then that's my own fault for treating the
internals list the brainstorming room at work!
I jump the gun often and write before thinking things through 100%; even
even I can see the namespace problem clearly enough to know that the
problem lies in php being both a procedural and OOP language, unless you
remove one or the other from namespaces there is always going to be a
level of ambiguity somewhere; IMO Greg's solution #2 (introducing ::: to
mark the end of a namespace) and stas' proposal #1 are the best I've
seen. Personally though I'd love to see stas' #1 get implemented and
"->" used for all functions in a namespace so..
one::step::two(); //always static method of class
one::step->two(); //always function of namespace.
But it's still ambiguous (only in a rarely though) - if an object with a
method "two" is assigned to the static variable of a class called one
then problem comes back.
I'd love to see a "perfect" solution; but know enough to realise it
isn't going to come from me (and may well be impossible) so bailing out.
I have to say this; the reason people like me pop on to internals and
give brainstorming not thoroughly thought through (or discussed)
opinions, is because there isn't a public "forum" for that kind of
thing, if there was a place where userland and the internal's could meet
up to even just discuss or thrash out ideas, get opinions, votes,
whatever then it would alleviate the problem.
Regards & Happy Weekend
Nathan
--
nathan ( nathan@kraya.co.uk )
{
Senior Web Developer
php + java + flex + xmpp + xml + ecmascript
web development edinburgh | http://kraya.co.uk/
}
Nathan Rixham wrote:
seen. Personally though I'd love to see stas' #1 get implemented and
"->" used for all functions in a namespace so..
one::step::two(); //always static method of class
one::step->two(); //always function of namespace.But it's still ambiguous (only in a rarely though) - if an object with a
method "two" is assigned to the static variable of a class called one
then problem comes back.
First of all, this is not going to happen (voted down). Second of all
one::$step
is how static variables are accessed, not one::step. So there is no
potential for conflict.
Greg
Gregory Beaver wrote:
Nathan Rixham wrote:
seen. Personally though I'd love to see stas' #1 get implemented and
"->" used for all functions in a namespace so..
one::step::two(); //always static method of class
one::step->two(); //always function of namespace.But it's still ambiguous (only in a rarely though) - if an object with a
method "two" is assigned to the static variable of a class called one
then problem comes back.First of all, this is not going to happen (voted down). Second of all
one::$step
is how static variables are accessed, not one::step. So there is no
potential for conflict.Greg
right enough; there is no conflict joy; and it's not introducing any
new separator's into php, and I think it makes logical sense /ponders/
I've been flittering between java, as3 and php all week and ended up
highly confused, ditsy and using the wrong syntax everywhere - so
apologies for my ramblings!
cheers for the reply; and thanks for all you're hard work on the
namespaces; the RFC you wrote on the wiki really outlined the problem
perfectly and made it more accessible to the masses.
Many Regards
Nath
--
nathan ( nathan@kraya.co.uk )
{
Senior Web Developer
php + java + flex + xmpp + xml + ecmascript
web development edinburgh | http://kraya.co.uk/
}