Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41305
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.92.174 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:references;
        b=MQpPcKlACMtaZlNGlzC3xImTGMlKYUa/tZUJCOOuggJWWHXmkq3LgreZ5vk6OyGbF4
         LuRG2CcC5w3K0R9DsCD7kxtfpX1Uwv/n2nQXOUdrzZv20CjjpSco/dr7/iliUs2qUvLy
         sL+EpZOrAWL9Gdcp6VUhOwSD4BL/z81UGV9x8=
Message-ID: <9b3df6a50810210117n5f387b91tb9cb04d48db72037@mail.gmail.com>
Date: Tue, 21 Oct 2008 11:17:54 +0300
To: "Stan Vassilev | FM" <sv_forums@fmethod.com>
Cc: internals@lists.php.net
In-Reply-To: <646095388F084934B3647141FF1B459C@pc>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_1567_8566667.1224577074508"
References: <48F89F19.9040405@croscon.com> <3D.16.21706.F3CCCF84@pb1.pair.com>
	 <015101c932e3$a37fb370$3ffc1f3e@foxbox>
	 <200810202046.51235.et@php.net>
	 <015c01c932e5$3671ff70$3ffc1f3e@foxbox>
	 <8c35d7690810201245y29abc7ffo528fa3f9391fad01@mail.gmail.com>
	 <48FCFA26.6010703@gmail.com> <022d01c932f6$202eee60$3ffc1f3e@foxbox>
	 <646095388F084934B3647141FF1B459C@pc>
Subject: Re: [PHP-DEV] Namespace issues
From: arvids.godjuks@gmail.com ("Arvids Godjuks")

------=_Part_1567_8566667.1224577074508
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

2008/10/21 Stan Vassilev | FM <sv_forums@fmethod.com>

>
> Hi,
>
> Guys, this is like junior school in here.
>
> Let me put some things in perspective:
>
> 1) The location of backslash on foreign keyboard is entirely irrelevant for
> the choice of namespace separator. Why? You already use this *every day* to
> escape characters in your strings and regular expressions. Anyone complained
> about the location of backslashes in there? No.
>
> 2) Where the backslash is, is also where the {} and [] are on those
> kayboards, as some people already said.
>
> 3) "Backslash is ugly" <-- are you honest? Which is uglier:    :::Foo()
> ::Foo()  or \Foo();  The last one at least has intuitive meaning (like file
> paths: absolute path). Face it that you'll be typing either one of the above
> three a *lot*, and pick one that makes sense visually and for newcomers
> alike. I think that's the backslash.
>
> 4) "But we want the same operator". Well? I want a pony, the fact is
> however, the other languages have the design to afford the same separator
> for namespaces, static methods and members. Shoehorning this in PHP while
> maintaing BC will create such nightmares in big projects with ambigous
> identifiers, autoload performance issues, that you'd wish you go back and
> change the damn namespace operator to just about *anything* but "::".
>
> I wish the people who have a clear opinion of the above voice their
> opinion. For those who aren't quite sure what the issues in point 4 are,
> please just stay low and follow the list until you do.
>
> Regards,
> Stan Vassilev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> Exactly my feeling. When it comes to dealings with 15+ MB codes (after
excluding all 3-rd parity libraries), ambiguity problem becomes real even
now. It's hard enough to think of good name for 2 similar, but different in
realisation modules, so that you understand what they are for and to
understand what is different between them. I deal with 3 projects 50 MB +-
in size every day, jumping from one to other sometimes few times a day. such
projects 100% have large amount of variables named equaly. If you begin to
implement namespace support and access them outside namespaces, it becomes a
nightmare to understand what it accessed.
I see two solutions:
1). Change the separator.
2). Don't allow function, class, constant and variable naming same as
namespace name. Make it a fatal error. Then this will be solved.

Other options like throwing something away or make an ambigity resolution
mechanism personaly me don't make happy. Throwing something away leaves us
with something half working. Ambigity resolution mechanism makes us to
remember what is what (scrolling up and down tens of times a day is realy
disturbing the work), but is for sure better than first one.

If we combine all good things from all proposals, we can get one big solid
thing. Just my IMHO, but still:
1). Change the separator.
2). Make resolution to global classes, functions, constants first and if not
found - then to namespace. But realy, may be use self to point to namespaced
function, class, method ? Same as $this in classes. That seems logical,
because PHP is already using such mechanism.
3). Don't allow ambigity naming. Die with E_FATAL in such cases, don't allow
thouse coders to write bad code, please do! I beg you!

I don't know how parser works exactly, but maybe constant ambigity could be
resolved by patch, witch resolves constant values at compile time. If that
can't be done, than issue E_FATAL.

Just my IMHO. Please, don't make a holly war of my post. I wount argue with
holly war responces. Just tell me where I'm wrong and if that's because of
implementation difficulties - explain, I will understand that techno bable
:)

------=_Part_1567_8566667.1224577074508--