Ronald Chmara wrote:
On Oct 17, 2008, at 3:53 AM, Nathan Rixham 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:
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 ( [EMAIL PROTECTED] )
{
Senior Web Developer
php + java + flex + xmpp + xml + ecmascript
web development edinburgh | http://kraya.co.uk/
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
