Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41252
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.182.184 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:reply-to:organization:user-agent:mime-version:to:cc
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding:from;
        b=vyblRCEALo0hqv3+rGoT5RkhPY2X32fo9xdG+a+Q2nTUV1CVaoYIBTrsAwm+WBcGRh
         o/QoC7LpZ0cPqRH6ALuBdycXjk0of6wsOY7SturIVgNxoPgVv07lrk8iQjEpj8xpAVyH
         /4U6THXdj7RX/x+tQf//7sZSGw99Cpn5pXYqw=
Message-ID: <48F9FBDC.9030300@kraya.co.uk>
Date: Sat, 18 Oct 2008 16:08:12 +0100
Reply-To: nathan@kraya.co.uk
Organization: Kraya Ltd
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Ronald Chmara <ron@Opus1.COM>
CC: internals@lists.php.net, steph@php.net
References: <48F86EB4.5080308@kraya.co.uk> <3E52781C-3CD6-4A44-86B7-2682EC25AEA3@opus1.com>
In-Reply-To: <3E52781C-3CD6-4A44-86B7-2682EC25AEA3@opus1.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] UltraSimple Namespace Solution
From: nrixham@gmail.com (Nathan Rixham)

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 ( nathan@kraya.co.uk )
{
  Senior Web Developer
  php + java + flex + xmpp + xml + ecmascript
  web development edinburgh | http://kraya.co.uk/
}