Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41443
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.188 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=Onk93xUtJO+X0rOBr37KpO1wJg+FUk0WBJD+csFiaUcpQO9ntS4LxnLT2WSz78v9kf
         ZyR4yx3IIheJsRCmf/Q1y3r7TY4lJ2H9C8AWCxzKPvwvmXS4PNJ/7U2rZ6cDz7Qa0hjd
         0PIyu0tIBnFRTGNQH8/HyJdmFw2pFG2IJonUU=
Message-ID: <d1bff87d0810270529j39b4ec16j3e7e0cfecfc112ce@mail.gmail.com>
Date: Mon, 27 Oct 2008 14:29:22 +0200
To: "Alain Williams" <addw@phcomp.co.uk>
Cc: "PHP internals" <internals@lists.php.net>
In-Reply-To: <20081027121602.GY30862@mint.phcomp.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <d1bff87d0810260351n4361e42n62b86165ef56c70@mail.gmail.com>
	 <49047D62.1030900@lsces.co.uk> <49059FC1.2060702@vector-seven.com>
	 <9b3df6a50810270411t2b8e050au33d68564225311d4@mail.gmail.com>
	 <4905A81F.3070506@vector-seven.com>
	 <20081027121602.GY30862@mint.phcomp.co.uk>
Subject: Re: [PHP-DEV] RE: </endnamespacediscussion>
From: tudor.prodan@gmail.com ("Tudor Prodan")

I agree with Thomas Lee, if the backslash ever gets released, it's
there forever.

Who uses functions and variables in a namespace anyway? very few
Will that small part of the users even use namespaces? probably not

So, why not ban these from namespaces and save all the trouble?
If however a user will want to do this the bad way, he can always use statics.
This way all the trouble is dumped on that small part of users that,
again, will most likely not even use namespaces to begin with.

\Tudor



On Mon, Oct 27, 2008 at 2:16 PM, Alain Williams <addw@phcomp.co.uk> wrote:
> I apologise for being silent on this issue to date (been busy), but I feel that
> I must comment even if the decision is now 'final'.
>
> On Mon, Oct 27, 2008 at 10:38:07PM +1100, Thomas Lee wrote:
>> I disagree that PHP being a dynamic language justifies the introduction
>> of deeply unpopular syntax. I mean, PHP developers are your end users.
>> Bad past design decisions aside, you don't want to alienate your users.
>>
>> And yes, this has probably been argued in the past. Unfortunately, it
>> looks like you have people's attention *now*.
>
> Like mine.
>
> The backslash character will cause much WTF to even experienced people.
> \ is just too *magic* in all sorts of ways.
>
> Trying to interpolate into a string is one that will cause huge problems.
>
> How about :.: -- OK it is a bit longer, but is clear, it doesn't suffer from the
> problem that ::: has (ie 2 or 3 ':'s leading to errors). I believe that '.' and ':'
> are available on most national language keyboards.
>
> The real problem is that we have run out of extra symbols.
>
> If you don't like the suggestion above, there are many others in that family, eg:
>
>        :=: :+: :_: :-: :@: <:> <@>
>
>
> The other thing that has always puzzled me about namespaces is that they do NOT
> include varaibles - one of the things that I would most want to wrap up in a namespace.
> I accept that variables in a namespace would not be in $GLOBALS, but that is no great
> loss ... if people *really* want it we could always define: $_NAMESPACEVARS['foo:.:bar']
> as an array of variables in namespace foo:.:bar.
> Maybe $_NAMESPACES would be an array of all namespaces that are defined.
>
> --
> Alain Williams
> Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
> +44 (0) 787 668 0256  http://www.phcomp.co.uk/
> Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
> Past chairman of UKUUG: http://www.ukuug.org/
> #include <std_disclaimer.h>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>