# UltraSimple Namespace Solution - Thread: https://externals.io/message/41209 - Original archive: https://news-web.php.net/php.internals/41209 - Started by Nathan Rixham on 2008-10-17T10:53:40+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #41209 — Nathan Rixham — 2008-10-17T10:53:40+00:00 URL: https://externals.io/message/41209#41209 *The Problem (as defined by Greg):* foo.php: main.php: *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 --- ## #41211 — Ron Rademaker — 2008-10-17T11:00:34+00:00 URL: https://externals.io/message/41209#41211 · In reply to: #41209 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 --- ## #41212 — Derick Rethans — 2008-10-17T11:02:02+00:00 URL: https://externals.io/message/41209#41212 · In reply to: #41209 > 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 --- ## #41213 — Vesselin Kenashkov — 2008-10-17T11:02:42+00:00 URL: https://externals.io/message/41209#41213 · In reply to: #41209 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: > namespace one::step; > function two(){} > > namespace one; > class step { > static function two(){} > } > ?> > > main.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 --- ## #41251 — Ronald Chmara — 2008-10-18T04:36:58+00:00 URL: https://externals.io/message/41209#41251 · In reply to: #41209 > > *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: 1. PHP is heading towards broad i18n. How do you "uppercase" or "lowercase" written languages that don't have a concept of case? 2. 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*. 3. 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": 1. 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 --- ## #41252 — Nathan Rixham — 2008-10-18T15:08:12+00:00 URL: https://externals.io/message/41209#41252 · In reply to: #41251 Ronald Chmara wrote: > > > > […] > > Assuming this is a real question: > > 1. PHP is heading towards broad i18n. How do you "uppercase" or > "lowercase" written languages that don't have a concept of case? > > 2. 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*. > > 3. 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": > 1. 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/ } --- ## #41254 — Gregory Beaver — 2008-10-18T15:47:38+00:00 URL: https://externals.io/message/41209#41254 · In reply to: #41252 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 --- ## #41255 — Nathan Rixham — 2008-10-18T16:31:52+00:00 URL: https://externals.io/message/41209#41255 · In reply to: #41254 Gregory Beaver wrote: > Nathan Rixham wrote: > > > […] > > 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/ }