# Namespace issues

- Thread: https://externals.io/message/41218
- Original archive: https://news-web.php.net/php.internals/41218
- Started by Marcel Esser on 2008-10-17T14:20:09+00:00
- Messages: 27
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/41218.md?page=2
- 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

---

## #41218 — Marcel Esser — 2008-10-17T14:20:09+00:00

URL: https://externals.io/message/41218#41218

Using ::: as a namespace seperator would be great.

---------------------------------------
Marcel Esser, Technical Lead
Croscon, LLC
http://www.croscon.com

---

## #41240 — William A. Rowe — 2008-10-17T17:57:53+00:00

URL: https://externals.io/message/41218#41240 · In reply to: #41218

Marcel Esser wrote:
> Using ::: as a namespace seperator would be great.

A general rule of telephony dialing and other data input, three of
the same character will too often be entered or recognized as two
or four characters due to user or mechanical error.  That's why
when you see mnemonic phone numbers they rarely repeat three
digits in the middle (three 0's at the end for example aren't
subject to the excess fourth repetition problem).

---

## #41266 — Marcus Boerger — 2008-10-18T21:03:50+00:00

URL: https://externals.io/message/41218#41266 · In reply to: #41240

Hello William,

Friday, October 17, 2008, 7:57:53 PM, you wrote:

> Marcel Esser wrote:
> > […]

> A general rule of telephony dialing and other data input, three of
> the same character will too often be entered or recognized as two
> or four characters due to user or mechanical error.  That's why
> when you see mnemonic phone numbers they rarely repeat three
> digits in the middle (three 0's at the end for example aren't
> subject to the excess fourth repetition problem).

This is the major flaw with that solution. Personally I just looked at
working code that had (:::) and (\) which is the second option I also
mentioned already long ago. And (:::) can be read very easy. The visual
difference to (::) is big enough. However it is too easy to either type
two or four. Thus the backslash (the only other conflict free) character
is probably the better option - even though no one has done something
like that. Btw, it pretty much suggests thatyou use the same structure
for your directories and files. Which you'd do inside __autoload() most
likely anyway.

Best regards,
 Marcus

---

## #41268 — Marcus Boerger — 2008-10-18T21:56:54+00:00

URL: https://externals.io/message/41218#41268 · In reply to: #41266

Hello all,

  Greg was so kind to give me part of his awesome upcoming Pyrus code. He
actually has it running with both ':::' and '\' as namespace separators.
So I thought I'd help out a tiny tiny bit by giving you all the choice of
having a look at actual working code:

http://php.net/~helly/triplecolon.html
http://php.net/~helly/triplecolon-colored.html
http://php.net/~helly/backslash-colored.html
http://php.net/~helly/backslash.html

marcus


Saturday, October 18, 2008, 11:03:50 PM, you wrote:

> Hello William,

> Friday, October 17, 2008, 7:57:53 PM, you wrote:

> > […]

> > […]

> This is the major flaw with that solution. Personally I just looked at
> working code that had (:::) and (\) which is the second option I also
> mentioned already long ago. And (:::) can be read very easy. The visual
> difference to (::) is big enough. However it is too easy to either type
> two or four. Thus the backslash (the only other conflict free) character
> is probably the better option - even though no one has done something
> like that. Btw, it pretty much suggests thatyou use the same structure
> for your directories and files. Which you'd do inside __autoload() most
> likely anyway.

> Best regards,
>  Marcus





Best regards,
 Marcus

---

## #41269 — Nathan Rixham — 2008-10-18T23:49:33+00:00

URL: https://externals.io/message/41218#41269 · In reply to: #41268

Marcus Boerger wrote:
> Hello all,
> 
>   Greg was so kind to give me part of his awesome upcoming Pyrus code. He
> actually has it running with both ':::' and '\' as namespace separators.
> So I thought I'd help out a tiny tiny bit by giving you all the choice of
> having a look at actual working code:
> 
> http://php.net/~helly/triplecolon.html
> http://php.net/~helly/triplecolon-colored.html
> http://php.net/~helly/backslash-colored.html
> http://php.net/~helly/backslash.html
> 
> marcus
> 

Thanks massively! Those code samples make it vastly clear just how many 
times we'll all be calling functions in the default namespace - and I 
for one don't fancy typing ::: for every function or normal PHP class I 
ever use! + \strpos() etc. just looks and types natural to me.

I realise we wouldn't /have/ to type \ or ::: every time we call a 
'normal' function, but I for one would prefer to by way of good 
practise, and those extra chars make a huge difference as far as I'm 
concerned.

I do not want to spend the rest of my life typing ::: in front of every 
function.

note: it type's natural as the \ is right beside zxcv on my keyboard, 
which I'm ctrl+tapping all the time, so comes natural to my pinky!

This is a no-brainer AFAIK.

Thanks again (really),

Nathan

---

## #41270 — Nathan Rixham — 2008-10-18T23:51:33+00:00

URL: https://externals.io/message/41218#41270 · In reply to: #41268

Marcus Boerger wrote:
> Hello all,
> 
>   Greg was so kind to give me part of his awesome upcoming Pyrus code. He
> actually has it running with both ':::' and '\' as namespace separators.
> So I thought I'd help out a tiny tiny bit by giving you all the choice of
> having a look at actual working code:
> 
> http://php.net/~helly/triplecolon.html
> http://php.net/~helly/triplecolon-colored.html
> http://php.net/~helly/backslash-colored.html
> http://php.net/~helly/backslash.html
> 
> marcus
> 

shift+;(x3) vs \

---

## #41271 — Catalin Zamfir Alexandru | KIT Software CAZ — 2008-10-18T23:58:57+00:00

URL: https://externals.io/message/41218#41271 · In reply to: #41270

Quicker shift + ; x 3 than finding that freakin backslash on my HP 530 notebook.

----------------------------



> -----Original Message-----
> From: Nathan Rixham [mailto:nrixham@gmail.com]
> Sent: Sunday, October 19, 2008 2:52 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Namespace issues
> 
> Marcus Boerger wrote:
> > […]
> He
> > […]
> separators.
> > […]
> of
> > […]
> 
> shift+;(x3) vs \

---

## #41272 — Steph Fox — 2008-10-19T00:21:12+00:00

URL: https://externals.io/message/41218#41272 · In reply to: #41270

> > […]

I did say off-list that Nathan would be an immediate fan...
(Nathan actually proposed this off-list during the survey, not knowing that 
the idea had been rejected 4 years or so back.)

Revisiting this.. isn't a crime. It's the one ns separator we have available 
in PHP that won't mess up for people with bad eyesight, for one. Among 
developers, that's quite a big deal.

The big question is whether we need a namespace separator at all. As far as 
I'm aware, this is still under investigation (and this time it's for real).

- Steph

> > […]
>
> shift+;(x3) vs \

---

## #41273 — Lester Caine — 2008-10-19T07:04:25+00:00

URL: https://externals.io/message/41218#41273 · In reply to: #41270

Nathan Rixham wrote:
> > […]
> shift+;(x3) vs \

And there are no problems with those on foreign keyboards?
I recall seeing a number of 'complaints' about some of the separator 
characters that are difficult to access on foreign language keyboards. Has 
anybody tabulated that so that the extent of that problem is understood?

Just an aside, and while I might put changing the separator used above adding 
'use namespace', from a documentation and review of code where multiple files 
are involved, going with both ( keeping finger of shift key which it goes to 
automatically ;) ) makes perfect sense to me.

But do I still understand that there is an alternative method that was not 
part of this last round of voting? And needs to be reviewed in light of the 
current 'consensus' ?
( putting quotes around a word is automatic to me as well - just means that 
the word may not be entirely appropriate but gives the right idea )

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

---

## #41274 — David Coallier — 2008-10-19T11:02:21+00:00

URL: https://externals.io/message/41218#41274 · In reply to: #41273

> > […]
>

Ok I'll try to make a very neutral comment. For the moment most are
still using an english keyboard (no matter which english in this case
and I'd actually be interested in knowing numbers for a fact if
anyone's got something) and ergonomically speaking, ::: is much easier
to type than \ for those who actually learned to type with the adsf
jkl; keyboard. When you learn typing you usually learn to type using
the left-hand side shift key for "most" of the letters/words, for
instance typing : doesn't require a movement of the right hand since
your pinky is already on the ; key whereas the \ key requires a
"not-so-used" movement of the hand.

Anyways, I was just saying that without considering the question
because I absolutely don't feel like redicussing this over and over.
We have had a massive list fight over 3-4 years ago about it and I'm
not getting into this one.



-- 
Slan,
David

---

## #41275 — Marcus Boerger — 2008-10-19T11:24:43+00:00

URL: https://externals.io/message/41218#41275 · In reply to: #41274

Hello David,

Sunday, October 19, 2008, 1:02:21 PM, you wrote:

> > […]

> Ok I'll try to make a very neutral comment. For the moment most are
> still using an english keyboard (no matter which english in this case
> and I'd actually be interested in knowing numbers for a fact if
> anyone's got something) and ergonomically speaking, ::: is much easier
> to type than \ for those who actually learned to type with the adsf
> jkl; keyboard. When you learn typing you usually learn to type using
> the left-hand side shift key for "most" of the letters/words, for
> instance typing : doesn't require a movement of the right hand since
> your pinky is already on the ; key whereas the \ key requires a
> "not-so-used" movement of the hand.

> Anyways, I was just saying that without considering the question
> because I absolutely don't feel like redicussing this over and over.
> We have had a massive list fight over 3-4 years ago about it and I'm
> not getting into this one.

All good points :-)

So for typing it sounds to me like both would work as a compromise well
enough. Also on a german keyboard layout a backslash is in the same
category than the ':'. Personally I think however that I would to often
confuse myself with typing '::' vs ':::'. Often enough I find myself typing
the wrong char, typing delete as many times as necessary to go back to the
wrong char and then typing correct again. And in those case I mostly do not
look at the screen. I look at the keyboard to ensure I type what I wanted,
fixing my hand position, no longer seeing whether that is what I needed to
type. And this works for '::' vs '\' becasue they are completely different
but I think it does not work for '::' vs ':::', simply becasue that is not
a different enough and probably I know what to type always but confusing
myself with hitting the key the right amount of times.

The other parts are:
a) do we need one - I think so - because it means we solve any issue once
and forever
b) what reads better ':::' or '\'. Personally I think both work fine for
me. But I agree with Steph that other people might have a hard time
differenciating them.

> -- 
> Slan,
> David




Best regards,
 Marcus

---

## #41276 — Steph Fox — 2008-10-19T11:36:17+00:00

URL: https://externals.io/message/41218#41276 · In reply to: #41273

Hi Lester,

> And there are no problems with those on foreign keyboards?

If there are, those foreign keyboards are unable to offer either escaped 
chars or MS paths... which seems highly unlikely.

> But do I still understand that there is an alternative method that was not 
> part of this last round of voting? And needs to be reviewed in light of 
> the current 'consensus' ?

It was linked from Greg's proposals too: 
http://wiki.php.net/rfc/namespaceref. Basically (assuming that we're saying 
we want ns support for functions/constants) Stas avoids the need for a 
second ns separator by using the syntax

Name->Member

for static access. The 'avoid the need for second ns separator' part of 
Stas' proposal has widespread support according to the poll, it's just a 
case of figuring a way to manage this without introducing ambiguity into the 
code.

Both Stas' proposal and Greg's option #3 are flawed in that way (either to 
humans or to the Engine), so the search is on to find a solution that isn't 
ambivalent to either - always assuming it's possible.

- Steph

---

## #41286 — Philipp Wagner — 2008-10-20T18:21:27+00:00

URL: https://externals.io/message/41218#41286 · In reply to: #41276

Hi,

Steph Fox wrote:
> Hi Lester,
> 
> > […]
> 
> If there are, those foreign keyboards are unable to offer either escaped
> chars or MS paths... which seems highly unlikely.

Well, on German keyboards, it's accessible but only by using ALTGR+?,
which is not really a comfortable combination.

Philipp

---

## #41287 — Steph Fox — 2008-10-20T18:42:36+00:00

URL: https://externals.io/message/41218#41287 · In reply to: #41286

> Well, on German keyboards, it's accessible but only by using ALTGR+?,
> which is not really a comfortable combination.

Useful to know, thanks Philipp.

Any more localized keyboard issues we should know about? Anyone?

- Steph

---

## #41288 — Stefan Walk — 2008-10-20T18:46:50+00:00

URL: https://externals.io/message/41218#41288 · In reply to: #41287

On Monday 20 October 2008 20:42:36 Steph Fox wrote:
> > […]
>
> Useful to know, thanks Philipp.
>
> Any more localized keyboard issues we should know about? Anyone?
>
> - Steph

The "german keyboard" issue isn't really one. {}[] are in the same "class" of 
characters (alt-Gr + number-row). So, as a programmer, you either have to 
live with that anyway because there's no avoiding {}[], or you switch to the 
us layout while programming (which quite a few people do).

Regards,
Stefan

---

## #41289 — Steph Fox — 2008-10-20T18:53:58+00:00

URL: https://externals.io/message/41218#41289 · In reply to: #41288

> The "german keyboard" issue isn't really one. {}[] are in the same "class" 
> of
> characters (alt-Gr + number-row). So, as a programmer, you either have to
> live with that anyway because there's no avoiding {}[], or you switch to 
> the
> us layout while programming (which quite a few people do).

Also useful to know :)

- Steph

---

## #41290 — olafurw@gmail.com — 2008-10-20T19:45:02+00:00

URL: https://externals.io/message/41218#41290 · In reply to: #41289

On an icelandic keyboard "\" is AltGr + (key right of 0 in the top
row), just an fyi if you guys wanted to know.

For my two cents. "\" looks like its not supposed to be there.

Is there no other combination of two simbols that would work? Like >>
or +> or ** or .. or something in that fashion ?

Ólafur Waage

2008/10/20 Steph Fox <steph@php.net>:
> > […]
>
> Also useful to know :)
>
> - Steph

---

## #41299 — Ilia Alshanetsky — 2008-10-20T22:54:29+00:00

URL: https://externals.io/message/41218#41299 · In reply to: #41276

Another issue I just came across caused by :: being used for both  
namespaces and classes is the fact when it comes to validation such as  
the one I've just put it for constant names, its impossible to  
determine if the prefix is a namespace or a class name. So, I  
definitely think we should change :: to just about anything else, as  
long as its not :: I'd be happy.




> Hi Lester,
>
> > […]
>
> If there are, those foreign keyboards are unable to offer either  
> escaped chars or MS paths... which seems highly unlikely.
>
> > […]
>
> It was linked from Greg's proposals too: http://wiki.php.net/rfc/namespaceref 
> . Basically (assuming that we're saying we want ns support for  
> functions/constants) Stas avoids the need for a second ns separator  
> by using the syntax
>
> Name->Member
>
> for static access. The 'avoid the need for second ns separator' part  
> of Stas' proposal has widespread support according to the poll, it's  
> just a case of figuring a way to manage this without introducing  
> ambiguity into the code.
>
> Both Stas' proposal and Greg's option #3 are flawed in that way  
> (either to humans or to the Engine), so the search is on to find a  
> solution that isn't ambivalent to either - always assuming it's  
> possible.
>
> - Steph
>
> -- 
> 
> 
>

Ilia Alshanetsky

---

## #41301 — Ryan Panning — 2008-10-21T02:56:34+00:00

URL: https://externals.io/message/41218#41301 · In reply to: #41299

Ilia Alshanetsky wrote:
> Another issue I just came across caused by :: being used for both 
> namespaces and classes is the fact when it comes to validation such as 
> the one I've just put it for constant names, its impossible to determine 
> if the prefix is a namespace or a class name. So, I definitely think we 
> should change :: to just about anything else, as long as its not :: I'd 
> be happy.

LOL, this is never ending.

I was on the "change ::" bandwagon before realizing it won't fix 
everything. Would changing the element separator help you in this case? 
IMO, using a element separator would fix both ambiguity and help 
autoload. I'm still for option #2, though it lost out already. ;)

---

## #41302 — Derick Rethans — 2008-10-21T07:33:13+00:00

URL: https://externals.io/message/41218#41302 · In reply to: #41286

> Steph Fox wrote:
> > […]
> 
> Well, on German keyboards, it's accessible but only by using ALTGR+?,
> which is not really a comfortable combination.

So in your editor, map ::: to \ and be done with it.... no big deal.

regards,
Derick

-- 
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

---

## #41303 — Stan Vassilev | FM — 2008-10-21T07:33:34+00:00

URL: https://externals.io/message/41218#41303

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

---

## #41304 — Vesselin Kenashkov — 2008-10-21T08:07:42+00:00

URL: https://externals.io/message/41218#41304 · In reply to: #41303

The N word discussion looks neverending...
solution #3 from Gregory solves the ambiguity so I dont see how it will
"create such nightmares in big projects with ambigous identifiers". I'm
using the :: operator for the last 6 months and I had no such issues even
without the fix (I'm not naming classes and namespaces in the same way, and
I dont see why I would need to do so). Have you tried using it?
If the __autoload performance problem is solved I dont see what is the
problem with the current separator. I would wait for the opinion of Gregory
and Stas Malyshev on this matter.
On the other hand I dont think the backslash is ugly, and I think that the
windows users will find it somewhat familiar for using it in tree structures
like the namespaces.


On Tue, Oct 21, 2008 at 10:33 AM, Stan Vassilev | FM
<sv_forums@fmethod.com>wrote:

>
> 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
>
> --
> 
> 
>
>


-- 
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com

---

## #41305 — Arvids Godjuks — 2008-10-21T08:17:54+00:00

URL: https://externals.io/message/41218#41305 · In reply to: #41303

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
>
> --
> 
> 
>
> 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
:)

---

## #41306 — Steph Fox — 2008-10-21T09:52:52+00:00

URL: https://externals.io/message/41218#41306 · In reply to: #41305

Hi,

> > […]

Yep.

> > […]

No, let me. Greg worked his butt off the entire weekend looking for the 
flaws in *all* the options available to us, including a couple of new ones 
that never even reached the list before he rejected them on technical 
grounds. Thanks to his efforts, we already have a pretty good picture of the 
strengths and weaknesses of each approach - and as should be obvious to all 
by now, there is no perfect solution. Whatever we chose, it's a compromise.

What we're hearing here about European keyboard layouts is useful info 
because it gives some idea of how popular/unpopular the backslash would be 
as a solution and why, but it shouldn't carry as much weight as the 
accessibility argument against the triple colon. One is liveable, if not 
optimal, whereas the other is plainly not liveable for some. We've already 
heard two workarounds for the backslash issues, but there are none at all 
for ::: + imperfect eyesight.

Clarity and simplicity are the two chief requisites. We're all fully aware 
of that, from Engine developer to n00b, so there's really no point in 
discussing it to death on-list at this stage.

- Steph

---

## #41307 — Catalin Zamfir Alexandru | KIT Software CAZ — 2008-10-21T11:44:24+00:00

URL: https://externals.io/message/41218#41307 · In reply to: #41306

> 
> Clarity and simplicity are the two chief requisites. We're all fully
> aware
> of that, from Engine developer to n00b, so there's really no point in
> discussing it to death on-list at this stage.
> 

Yep. I agree. I'm already tired of watching this thread. Let them agree
on an implementation that is going to work with THE LEAST AMOUNT of cons. - 
because some of us (that means me) really just want namespaces implemented, and
for one reason it doesn't really count what 'sign' it's used to mark a namespace,
as much as the functionality they bring.

As long as my PHP job depends on developing extremelly simple methods/functions
for our noobish PHP developers, namespaces are a great functionality needed to
map 'same-name functions/methods' to a freakin' namespace that would be simple to
use for the average PHP developer.

So, my Nike-borrowed motto is: "Just do it (already!) ..." ...

---

Next page: https://externals.io/message/41218.md?page=2