Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] RE: </endnamespacediscussion>

Posted by Tudor Prodan 
Tudor Prodan
[PHP-DEV] RE: </endnamespacediscussion>
October 26, 2008 11:55AM
Hi,

PHP has to be unique, using the double colon notation would be too
cliche, but if we're not respecting conventions, why not go with
something more exotic? I've always liked the o with the slash trough
it. The e with the horizontal colon is also pretty nice. The n with
the tilde over it, it so strongly says _n_amespace.

When I read this message first thing I did was check the date, but
deep down I knew it wasn't April yet.

One of the top reasons why I hate using windows consoles is the
dreaded "\" character.

Each and every keyboard model I have has this key in a different
place, sometimes one hard to reach. Every time I'm in doing a cd in
windows I press 2-3 other keys while going for the backslash.

That whole rating table over on the PHP wiki is just ridiculous.
- type-ability: come on. If anything, it should get -1 there
- typo-vulnerability: pretty big, but I think most problems will be
escaping rather than typos anyway
- number of chars: any sane person will agree that you can write
"::" a lot faster than "\"
- editor integration: not really, many editors will have trouble, including vim

I eagerly await namespaces in PHP, but guys, if you don't have a good
idea, I think copying is better than implementing a bad one.

\Tudor

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 26, 2008 03:25PM
Tudor Prodan wrote:
> PHP has to be unique, using the double colon notation would be too
> cliche, but if we're not respecting conventions, why not go with
> something more exotic? I've always liked the o with the slash trough
> it. The e with the horizontal colon is also pretty nice. The n with
> the tilde over it, it so strongly says _n_amespace.
>
> When I read this message first thing I did was check the date, but
> deep down I knew it wasn't April yet.
>
> One of the top reasons why I hate using windows consoles is the
> dreaded "\" character.
>
> Each and every keyboard model I have has this key in a different
> place, sometimes one hard to reach. Every time I'm in doing a cd in
> windows I press 2-3 other keys while going for the backslash.
>
> That whole rating table over on the PHP wiki is just ridiculous.
> - type-ability: come on. If anything, it should get -1 there
> - typo-vulnerability: pretty big, but I think most problems will be
> escaping rather than typos anyway
> - number of chars: any sane person will agree that you can write
> "::" a lot faster than "\"
> - editor integration: not really, many editors will have trouble, including vim
>
> I eagerly await namespaces in PHP, but guys, if you don't have a good
> idea, I think copying is better than implementing a bad one.

Tudor - There is little point reiterating half of the facts. There are very
good reasons why - for PHP - a simple solution was not working. MANY people
were coming up with problems as to why the currently implemented 'solution'
was only going to create a black hole at some point, and what ever was doing
to be done was going to cause problems somewhere.

The backslash is not ideal, but I think we all need to get behind it rather
than complaining. The only other real alternative today is to shelve
namespaces altogether for the next release rather than putting something in
that is simply not practical to extend later?

Given the polarised views a total solution that everybody could agree with was
just not happening!

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tudor Prodan
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 10:35AM
Well, given how much PHP has copied from C (and I mean that in a good
way), why not copy the sane, less-controversial namespace separator
and behavior that we all know and love?

\Tudor



On Sun, Oct 26, 2008 at 4:23 PM, Lester Caine <[email protected]> wrote:
> Tudor Prodan wrote:
>>
>> PHP has to be unique, using the double colon notation would be too
>> cliche, but if we're not respecting conventions, why not go with
>> something more exotic? I've always liked the o with the slash trough
>> it. The e with the horizontal colon is also pretty nice. The n with
>> the tilde over it, it so strongly says _n_amespace.
>>
>> When I read this message first thing I did was check the date, but
>> deep down I knew it wasn't April yet.
>>
>> One of the top reasons why I hate using windows consoles is the
>> dreaded "\" character.
>>
>> Each and every keyboard model I have has this key in a different
>> place, sometimes one hard to reach. Every time I'm in doing a cd in
>> windows I press 2-3 other keys while going for the backslash.
>>
>> That whole rating table over on the PHP wiki is just ridiculous.
>> - type-ability: come on. If anything, it should get -1 there
>> - typo-vulnerability: pretty big, but I think most problems will be
>> escaping rather than typos anyway
>> - number of chars: any sane person will agree that you can write
>> "::" a lot faster than "\"
>> - editor integration: not really, many editors will have trouble,
>> including vim
>>
>> I eagerly await namespaces in PHP, but guys, if you don't have a good
>> idea, I think copying is better than implementing a bad one.
>
> Tudor - There is little point reiterating half of the facts. There are very
> good reasons why - for PHP - a simple solution was not working. MANY people
> were coming up with problems as to why the currently implemented 'solution'
> was only going to create a black hole at some point, and what ever was doing
> to be done was going to cause problems somewhere.
>
> The backslash is not ideal, but I think we all need to get behind it rather
> than complaining. The only other real alternative today is to shelve
> namespaces altogether for the next release rather than putting something in
> that is simply not practical to extend later?
>
> Given the polarised views a total solution that everybody could agree with
> was just not happening!
>
> --
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Alexey Zakhlestin
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 10:45AM
On Mon, Oct 27, 2008 at 12:33 PM, Tudor Prodan <[email protected]> wrote:
> Well, given how much PHP has copied from C (and I mean that in a good
> way), why not copy the sane, less-controversial namespace separator
> and behavior that we all know and love?

because C is static, and PHP is dynamic
it was already discussed — browse archives, please

--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Vesselin Kenashkov
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 11:35AM
I want to express my happiness of finally having an agreement/solution for
the namespaces.
I have something like 70 000 LOC with namespaces (and a lot of static
calls/class consts) so it will take some time to convert it to \ but I'm
still very happy to have a solution. Like Karsten Dambekalns said in one of
the threads it is more important to have ns support than the precise way it
will be implemented/separator used, no matter that we have code written
already - we will modify it.
As a personal opinion - the backslash is fine for me because:
- it is only one character
- readable enough (something\another\thing)
- no BC (like the proposed#hash#sign)
- it will be somewhat familiar for the windows users (I'm not, but still is
a +)

I really hope that after testing the patch there will be no issues and this
solution will get into the final version (and will put the end of the ns
discussion). Big thanks to the people involved!

--
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com
Thomas Lee
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 12:05PM
Lester Caine wrote:
> The backslash is not ideal, but I think we all need to get behind it
> rather than complaining. The only other real alternative today is to
> shelve namespaces altogether for the next release rather than putting
> something in that is simply not practical to extend later?
I'd prefer to see it shelved for another release with the aim of fixing
whatever technical barriers made the syntax unworkable in the first
place. I'm sure you'd have plenty of volunteers.

My personal concern is that once this goes public, we (the end users)
are stuck with that decision for the forseeable future.

I think there's obviously enough unhappy campers here that this option
should be at least considered. Not that I'm holding my breath or anything.

Everybody seems to be getting awfully emotional about this ...

Cheers,
T


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Arvids Godjuks
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 12:15PM
This was argued for months, there was tons of emails to read and backslash
is best for most people. PHP is dynamic language - that makes some major
restrictions, so you just can't apply something that is already in use
easily. That's why :: was rejected in first place. That's why . was
rejected, other separators had other issues. Backslash is easy to see, easy
to type (most layouts have it without Shift or something else) and clearly
says - I'm a namespace!
So anyway - in any language you will find something that you would't like.
You just live with that or chouse another language. That's all.

2008/10/27 Thomas Lee <[email protected]>

> Lester Caine wrote:
>
>> The backslash is not ideal, but I think we all need to get behind it
>> rather than complaining. The only other real alternative today is to shelve
>> namespaces altogether for the next release rather than putting something in
>> that is simply not practical to extend later?
>>
> I'd prefer to see it shelved for another release with the aim of fixing
> whatever technical barriers made the syntax unworkable in the first place.
> I'm sure you'd have plenty of volunteers.
>
> My personal concern is that once this goes public, we (the end users) are
> stuck with that decision for the forseeable future.
>
> I think there's obviously enough unhappy campers here that this option
> should be at least considered. Not that I'm holding my breath or anything.
>
> Everybody seems to be getting awfully emotional about this ...
>
> Cheers,
>
> T
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Jevon Wright
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 12:35PM
So does that mean the new NS operator is actually \\ and not \ ?

No developer is going to be relying on single \'s -- too likely to become an
error in maintenence, and too inconsistent (see strings discussion).

Jevon

On Tue, Oct 28, 2008 at 12:11 AM, Arvids Godjuks
<[email protected]>wrote:

> This was argued for months, there was tons of emails to read and backslash
> is best for most people. PHP is dynamic language - that makes some major
> restrictions, so you just can't apply something that is already in use
> easily. That's why :: was rejected in first place. That's why . was
> rejected, other separators had other issues. Backslash is easy to see, easy
> to type (most layouts have it without Shift or something else) and clearly
> says - I'm a namespace!
> So anyway - in any language you will find something that you would't like.
> You just live with that or chouse another language. That's all.
>
> 2008/10/27 Thomas Lee <[email protected]>
>
> > Lester Caine wrote:
> >
> >> The backslash is not ideal, but I think we all need to get behind it
> >> rather than complaining. The only other real alternative today is to
> shelve
> >> namespaces altogether for the next release rather than putting something
> in
> >> that is simply not practical to extend later?
> >>
> > I'd prefer to see it shelved for another release with the aim of fixing
> > whatever technical barriers made the syntax unworkable in the first
> place.
> > I'm sure you'd have plenty of volunteers.
> >
> > My personal concern is that once this goes public, we (the end users) are
> > stuck with that decision for the forseeable future.
> >
> > I think there's obviously enough unhappy campers here that this option
> > should be at least considered. Not that I'm holding my breath or
> anything.
> >
> > Everybody seems to be getting awfully emotional about this ...
> >
> > Cheers,
> >
> > T
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
Thomas Lee
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 12:40PM
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*.

You're also right in that we can choose another language. I just wonder
why you'd be so eager to encourage it.

Anyway, my point is that there may be other options. Such as putting off
a long-sought feature until it can be implemented properly.

Cheers,
T

Arvids Godjuks wrote:
> This was argued for months, there was tons of emails to read and backslash
> is best for most people. PHP is dynamic language - that makes some major
> restrictions, so you just can't apply something that is already in use
> easily. That's why :: was rejected in first place. That's why . was
> rejected, other separators had other issues. Backslash is easy to see, easy
> to type (most layouts have it without Shift or something else) and clearly
> says - I'm a namespace!
> So anyway - in any language you will find something that you would't like.
> You just live with that or chouse another language. That's all.
>
> 2008/10/27 Thomas Lee <[email protected]>
>
>
>> Lester Caine wrote:
>>
>>
>>> The backslash is not ideal, but I think we all need to get behind it
>>> rather than complaining. The only other real alternative today is to shelve
>>> namespaces altogether for the next release rather than putting something in
>>> that is simply not practical to extend later?
>>>
>>>
>> I'd prefer to see it shelved for another release with the aim of fixing
>> whatever technical barriers made the syntax unworkable in the first place.
>> I'm sure you'd have plenty of volunteers.
>>
>> My personal concern is that once this goes public, we (the end users) are
>> stuck with that decision for the forseeable future.
>>
>> I think there's obviously enough unhappy campers here that this option
>> should be at least considered. Not that I'm holding my breath or anything.
>>
>> Everybody seems to be getting awfully emotional about this ...
>>
>> Cheers,
>>
>> T
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>
>


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 12:50PM
On Mon, 27 Oct 2008, 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*.
>
> You're also right in that we can choose another language. I just
> wonder why you'd be so eager to encourage it.
>
> Anyway, my point is that there may be other options. Such as putting
> off a long-sought feature until it can be implemented properly.

How would delyaing it help? We'd need to have the same discussion
anyway. If we could have made :: work, we would have. Greg (and others)
spend countless hours trying out different concepts, with different pros
and cons -- you can find those on the wiki as RFCs. The only way how
all issues could be solved was by picking a different namespace
separator. There would have been anything that could have changed this
without creating any sort of BC issues. From the possible namespace
separators, \ was the best one as we could see. That's how it is, that's
how it will be. Now get some coffee and quit bitching.

Derick

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Steph Fox
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 01:10PM
Hi Thomas,


> Anyway, my point is that there may be other options. Such as putting off a
> long-sought feature until it can be implemented properly.

OK, since you obviously didn't do any background reading before posting to
this list, let me direct you to the history behind this decision once again:
http://wiki.php.net/rfc/namespaceseparator. Let me also point out that this
only covers the last few weeks; the namespace discussions on this very list,
in-depth and otherwise, date back some 5 years.

If you read everything linked from that RFC, you will discover that there
are two ways to implement namespace support in PHP 'properly'.

1) We can offer support for classes only and throw a fatal error when a
function is encountered in namespaced code
2) We can use a namespace separator other than ::

There is of course always option 3...

3) We can drop the whole idea of namespace support because whatever is done
will appear 'wrong' to /. readers

Every other option leads to ambiguity in namespace syntax. That's not
because we need more time to think things over so it can be 'implemented
properly', it's just straight fact.

- Steph


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Alain Williams
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 01:20PM
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
Tudor Prodan
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 01:35PM
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 <[email protected]> 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
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
David Grudl
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 01:55PM
> On Mon, 27 Oct 2008, Thomas Lee wrote:
>
> How would delyaing it help?

I agree, delaying will not help (and namespaces are the most expected
feature in PHP 5.3).

> If we could have made :: work, we would have. Greg (and others)
> spend countless hours trying out different concepts, with different pros
> and cons -- you can find those on the wiki as RFCs.

But what is the purpose of namespaces? To give developers their own
separated space. And it is their responsibility to not use ambiguous
names. PHP has not problem with class Foo::Bar and namespace Foo::Bar,
but coding standards usually prohibits it.

Developers are not stupid. I think there is no reason to PHP trying be
smarter than them.

(I know, this is kind of philosopher argument, but the same thinking
works in C++ well).

The only way how
> all issues could be solved was by picking a different namespace
> separator. There would have been anything that could have changed this
> without creating any sort of BC issues. From the possible namespace
> separators, \ was the best one as we could see. That's how it is, that's

I will be glad for each separator, but :: is the best one :-))

David Grudl

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Vesselin Kenashkov
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 01:55PM
1. One user of namespaced constants & functions here... I dont like to use
objects for everything. I have very few constants & functions but I would
like them to remain constants & functions instead of converting them to
static classes or object methods.
2. One reason against dropping ns for functions & constants is that if you
drop them how you can namespace legacy (or to avoid that word, not OOP)
code? This way many libraries can not be namespaced and if you have a name
collision you will not be able to solve it using namespaces.
3. I prefer using\name\spaces instead of prefixing_my_classes. Here is why -
I want to organize my files in a hierarchical way in the file structure. A
possible solution withtout namespace using prefixes couldbe
level1_level2_classname (spliting the name by _). But if I want it to be
class_name? Then I have an confusion. And I personaly dislike camelCase and
level1_level2_className does not works for me.
Because of this I prefer to have namespaces instead of class prefixes. Then
I can do name\space\class_name.
4. When you have namespace you can short_the_long_class_name used multiple
times in your code importing the namespace and then using the 'shortcut'.

I put the last two just to explain why I prefer to have namespace with
whatever by separator instead of dropping them.


On Mon, Oct 27, 2008 at 2:29 PM, Tudor Prodan <[email protected]>wrote:

> 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 <[email protected]> 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
> >
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com
Thomas Lee
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 02:05PM
Steph Fox wrote:
> Hi Thomas,
>
>
>> Anyway, my point is that there may be other options. Such as putting
>> off a long-sought feature until it can be implemented properly.
>
> OK, since you obviously didn't do any background reading before
> posting to this list, let me direct you to the history behind this
> decision once again: http://wiki.php.net/rfc/namespaceseparator. Let
> me also point out that this only covers the last few weeks; the
> namespace discussions on this very list, in-depth and otherwise, date
> back some 5 years.
>

Actually I've been following namespaces for a fair while, but the issue
of :: being a problem wasn't really raised until a few weeks ago. So
while I'm aware of namespaces being under discussion for a fair while,
yesterday was the first I'd heard about a decision being made for the
backslash being used as a namespace separator. Sounds like I'm not the
only one.

Hope it all works out, either way.

Cheers,
T


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Thomas Lee
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 02:05PM
David Grudl wrote:
>
> But what is the purpose of namespaces? To give developers their own
> separated space. And it is their responsibility to not use ambiguous
> names. PHP has not problem with class Foo::Bar and namespace Foo::Bar,
> but coding standards usually prohibits it.
>
+1 to that.

Cheers,
T


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Steph Fox
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 02:30PM
Hi Thomas,

> Actually I've been following namespaces for a fair while, but the issue of
> :: being a problem wasn't really raised until a few weeks ago. So while
> I'm aware of namespaces being under discussion for a fair while, yesterday
> was the first I'd heard about a decision being made for the backslash
> being used as a namespace separator. Sounds like I'm not the only one.

OK, sorry if that seemed unfair. I should've aimed it at certain others
really ;)

You're correct, the :: issues were only fully understood when Greg took the
time to investigate the options thoroughly. So you didn't miss a lot.

Namespace *separator* discussions were long-winded and involved every Tom
Dick and Harry turning up on [email protected] with increasingly bizarre ideas,
every time the subject arose over the last few years. That was when the real
discussion of separator options took place.

Lukas simply summarized the issues around the available options in his table
during the irc discussion last Saturday, but the fact is he couldn't have
really known the criteria - or the available symbols - without having those
lengthy public discussions behind him. We couldn't have known his criteria
and symbol set were correct without that history either; we'd have been
stuck on 'why not :' forever.

> Hope it all works out, either way.

As do we all :)

- Steph


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sean Coates
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 03:40PM
> Actually I've been following namespaces for a fair while, but the
> issue of :: being a problem wasn't really raised until a few weeks
> ago.

I realize this isn't a terribly constructive comment as it doesn't
solve any problems, but I hope it's constructive in the way that it
actually causes people to do as Derick said and go get a coffee
instead of whining about syntax... AGAIN.

The issue of :: being a problem (causes ambiguity) was part of the
ORIGINAL namespace discussion that took place 3 years ago. Some of us
have been dealing with people complaining about this for 3 years (I
blogged about ::: and \ in 2005), and I'm very happy we've finally
come to a resolution. If the core developers chose another operator,
then DIFFERENT people would be whining, so it's lose-lose.

Now, sit back, relax, trust that the developers who chose this
actually have half a clue, and stop crying wolf
Stanislav Malyshev
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 05:30PM
Hi!

> If you read everything linked from that RFC, you will discover that
> there are two ways to implement namespace support in PHP 'properly'.
>
> 1) We can offer support for classes only and throw a fatal error when a
> function is encountered in namespaced code
> 2) We can use a namespace separator other than ::

These aren't the only ways.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Steph Fox
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 05:55PM
> These aren't the only ways.

OK.

4) Claim that there is no real problem in addressing ambiguous situations.


- Steph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 06:10PM
Hi!

> OK.
>
> 4) Claim that there is no real problem in addressing ambiguous situations.

This is not what I meant, but there's obviously neither use nor interest
in further discussing this topic as decision was already taken. I only
wish people would not start rewriting history as other opinions or
options didn't even exist so soon. I'm fine with making the choice, what
I'm not fine with is presenting the thing as there was never any other
options at all. We had plenty of options, maybe too many, we tried to
choose the best, time will tell if we succeeded. Memory hole is not
necessary for that.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Steph Fox
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 06:25PM
> This is not what I meant, but there's obviously neither use nor interest
> in further discussing this topic as decision was already taken. I only
> wish people would not start rewriting history as other opinions or options
> didn't even exist so soon. I'm fine with making the choice, what I'm not
> fine with is presenting the thing as there was never any other options at
> all. We had plenty of options, maybe too many, we tried to choose the
> best, time will tell if we succeeded. Memory hole is not necessary for
> that.

My apologies. I was talking about what we were left with by the time we
reached the point of needing a meeting. There were of course several
attempts (recent and not so recent) to retain :: because this is what
*everyone* would have preferred to do. I certainly didn't intend to leave
the impression that this hadn't been investigated fully, or that there
weren't several proposals of ways to get around the known problems.

- Steph



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] RE: </endnamespacediscussion>
October 27, 2008 08:30PM
Vesselin Kenashkov wrote:
> 1. One user of namespaced constants & functions here... I dont like to use
> objects for everything. I have very few constants & functions but I would
> like them to remain constants & functions instead of converting them to
> static classes or object methods.
> 2. One reason against dropping ns for functions & constants is that if you
> drop them how you can namespace legacy (or to avoid that word, not OOP)
> code? This way many libraries can not be namespaced and if you have a name
> collision you will not be able to solve it using namespaces.
> 3. I prefer using\name\spaces instead of prefixing_my_classes. Here is why -
> I want to organize my files in a hierarchical way in the file structure. A
> possible solution withtout namespace using prefixes couldbe
> level1_level2_classname (spliting the name by _). But if I want it to be
> class_name? Then I have an confusion. And I personaly dislike camelCase and
> level1_level2_className does not works for me.
> Because of this I prefer to have namespaces instead of class prefixes. Then
> I can do name\space\class_name.
> 4. When you have namespace you can short_the_long_class_name used multiple
> times in your code importing the namespace and then using the 'shortcut'.
>
> I put the last two just to explain why I prefer to have namespace with
> whatever by separator instead of dropping them.

I'm with you on that Vesselin. Will I use namespace - probably not, but I can
see straight away blocks of code in projects I'm involved with that require
functions at least in the namespace. SO they should be re-written? Probably,
but one of the tidiest ways of handling even that is to wrap the legacy code
in it's own namespace. If functions and constants were dropped simply to push
an incomplete solution through, then it would cause a lot more trouble than
the current flack. The result is not 'ideal' but it is perfectly functional
and from what I've seen so far WILL work with legacy code.

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login