Everything

php

Home » Project » Newsgroups » php.internals » namespace separator ideas »

namespace separator ideas

php.internals

Greg Beaver

20 years ago

Hi all,

I have only one caveat with the \ separator, which is that it is a
little bit too similar to division with /, and can result in some
confusing code like:

<?php
namespace name1 {
class name2{}
}
define('name1', 1);
define('name2', 2);

$a = new name1\name2;
$b = name1/name2;
?>

The same issue exists with all colon based separators (that sounds bad
when read the wrong way...) because of the ternary operator, and :: with
static classes/methods.

<?php
namespace name1 {
class name2{}
}
define('name1', 1);
define('name2', 2);
// this may be a parse error with the current namespace patch,
// but need not be if we use ->
class name1
{
const name2 = 1;
}

$a = new name1:::name2;
$b = name1::name2; // do you see the difference?  I get confused
?>

What about using the T_OBJECT_OPERATOR?  This is a parse error in
existing versions, and also implies some separation.

<?php
namespace name1 {
class name2{}
}
define('name1', 1);
define('name2', 2);
// this may be a parse error with the current namespace patch,
// but need not be if we use ->
class name1
{
const name2 = 1;
}

$a = new name1->name2;
$b = name1::name2;
?>

I also proposed on IRC using \\ as this is similar to netware driver
separators:

<?php
define('name1', 1);
define('name2', 2);

$a = new name1\\name2;
$b = name1/name2;
?>

However, I know Andrei hated this :).  I very much prefer the use of ->,
as this has the same advantage as :: of "rhyming" with current syntax.

Greg

Jessie Hernandez

20 years ago

I personally don't like any of these, but I just thought of this one:
"%%". Don't think it'll cause any problems at all, and look at the code:

<?php
$a = new name1%%name2;
$b = name1::name2; // I see the difference clearly
?>

What do you think? ":::" is more intuitive for me, but "%%" is an
acceptable alternative...

Regards,

Jessie

Greg Beaver wrote:

Matt Friedman

20 years ago

Hi, I've been following your conversations all day and think I might
have a nice idea for the namespace separator idea. Sorry to barge in
on your conversation but I think the following has value.

What about something like <- or <:: or even just <:

It makes sense to me because a namespace is akin to a parent of the
class and in a diagram I would use an arrow to point to the parent
from the child. At least there is some type of parent <- child
relation.

examples:
Namespace <:: ClassName
or
Namespace <- ClassName
or
Namespace <: ClassName

Unless I'm missing something these symbols should not conflict with
other ones. They also have more a PHP "feel".

This is the most semantically pleasing for me and it mirrors a common
convention and represents the actual relationship. In the language it
is nice when the symbols have an appearance representative of the
actual relationship.

When I see \ I think of ugly Windoze file paths. Also ::: seems awkward somehow.

Matt.

On 11/26/05, Jessie Hernandez <jrhernandez05@gmail.com> wrote:

> I personally don't like any of these, but I just thought of this one:
> "%%". Don't think it'll cause any problems at all, and look at the code:
>
> <?php
> $a = new name1%%name2;
> $b = name1::name2; // I see the difference clearly
> ?>
>
>
> What do you think? ":::" is more intuitive for me, but "%%" is an
> acceptable alternative...
>
>
> Regards,
>
> Jessie
>
>
> Greg Beaver wrote:
> > Hi all,
> >
> > I have only one caveat with the \ separator, which is that it is a
> > little bit too similar to division with /, and can result in some
> > confusing code like:
> >
> > <?php
> > namespace name1 {
> >     class name2{}
> > }
> > define('name1', 1);
> > define('name2', 2);
> >
> > $a = new name1\name2;
> > $b = name1/name2;
> > ?>
> >
> > The same issue exists with all colon based separators (that sounds bad
> > when read the wrong way...) because of the ternary operator, and :: with
> > static classes/methods.
> >
> > <?php
> > namespace name1 {
> >     class name2{}
> > }
> > define('name1', 1);
> > define('name2', 2);
> > // this may be a parse error with the current namespace patch,
> > // but need not be if we use ->
> > class name1
> > {
> >     const name2 = 1;
> > }
> >
> > $a = new name1:::name2;
> > $b = name1::name2; // do you see the difference?  I get confused
> > ?>
> >
> > What about using the T_OBJECT_OPERATOR?  This is a parse error in
> > existing versions, and also implies some separation.
> >
> > <?php
> > namespace name1 {
> >     class name2{}
> > }
> > define('name1', 1);
> > define('name2', 2);
> > // this may be a parse error with the current namespace patch,
> > // but need not be if we use ->
> > class name1
> > {
> >     const name2 = 1;
> > }
> >
> > $a = new name1->name2;
> > $b = name1::name2;
> > ?>
> >
> > I also proposed on IRC using \\ as this is similar to netware driver
> > separators:
> >
> > <?php
> > define('name1', 1);
> > define('name2', 2);
> >
> > $a = new name1\\name2;
> > $b = name1/name2;
> > ?>
> >
> > However, I know Andrei hated this :).  I very much prefer the use of ->,
> > as this has the same advantage as :: of "rhyming" with current syntax.
> >
> > Greg
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
-- Matt Friedman

Jessie Hernandez

20 years ago

Hi Mat,

Matt Friedman wrote:

> Hi, I've been following your conversations all day and think I might
> have a nice idea for the namespace separator idea. Sorry to barge in
> on your conversation but I think the following has value.
>
> What about something like <- or <:: or even just <:
>
> It makes sense to me because a namespace is akin to a parent of the
> class and in a diagram I would use an arrow to point to the parent
> from the child. At least there is some type of parent <- child
> relation.
>
> examples:
> Namespace <:: ClassName
> or
> Namespace <- ClassName
> or
> Namespace <: ClassName
>
> Unless I'm missing something these symbols should not conflict with
> other ones. They also have more a PHP "feel".
>

Hmm, "<:" doesn't look bad to me. I'd like to somehow conduct a poll to
see what most prefer (it would be great if we could add polls on
php.net). So far, I have these possibilites:

:::
:>
<::
<-
<:

> This is the most semantically pleasing for me and it mirrors a common
> convention and represents the actual relationship. In the language it
> is nice when the symbols have an appearance representative of the
> actual relationship.
>
> When I see \ I think of ugly Windoze file paths. Also ::: seems awkward somehow.
>
> Matt.
>

Yeah, I feel the same way for "\". ":::" seems OK to me, but of course,
I want to put what the majority prefer.

Regards,

Jessie

David Zülke

20 years ago

::: is best. :> and <: look like my favorite smilies. No way I could
ever use them in code ;)

- David

Am 26.11.2005 um 22:39 schrieb Jessie Hernandez:

Oliver Grätz

20 years ago

Jessie Hernandez schrieb:

> So far, I have these possibilites:
>
> :::
> :>
> <::
> <-
> <:

OK, now that Marcus threw a PostToLongException('bla'), I'd love to get
back to this.

Other suggestions were

:     ::        ->        ..       \

Now some requirements:

- needs to work without collisions in the parser
(seems to kill ":","::","->")
- should be easily distinguishable from other, similar operators
(seems to kill ":::")
- at least one person on earth should like it
(seems to kill "\")

This leaves us with:

:>    <::    <-    <:    ..

I personally do not like ".." but that's just one voice.
What about combinations with | (like ":|") ?

For a laugh I should ass this link:
The periodic table of Perl operators!
http://www.ozonehouse.com/mark/blog/code/PeriodicTable.pdf

OLLi

Oliver Grätz

20 years ago

Oliver Grätz schrieb:

>    :>    <::    <-    <:    ..

Whoops, forgot to add "%%"

Oliver Grätz

20 years ago

Oliver Grätz schrieb:

> Oliver Grätz schrieb:
>
>>   :>    <::    <-    <:    ..
>
>
> Whoops, forgot to add "%%"

I really like "%%":

- not on the PHP operators list
- not on the "Periodic table"
- no associations in my mind other than LaTeX comments
- just two characters
- loosely resembles the sibling :: but they'll never be mixed up
- looks OK (Pear%%Date)

OLLi

Matthew Charles Kavanagh

20 years ago

On Sun, 2005-11-27 at 00:58 +0100, Oliver Grätz wrote:

> - looks OK (Pear%%Date)

You're kidding, right? %% looks nothing but blocky and messy to my human
eyes, and the resemblance to :: stretches the word "tenuous" to its
limit.

Jasper Bryant-Greene

20 years ago

Oliver Grätz wrote:

> Oliver Grätz schrieb:
>>    :>    <::    <-    <:    ..
>
> Whoops, forgot to add "%%"
>

+1 for <- here. It makes namespace hierarchies resemble diagrams of the
same hierarchies (like inheritance in UML). It also visually makes
sense, isn't hard to type, and doesn't look like a smiley (like :> etc).

--
Jasper Bryant-Greene
General Manager
Album Limited

+64 21 708 334
jasper@album.co.nz

Eric Coleman

20 years ago

I'd have to vote for either <- or :>.  I perfer the later.

\ is kinda crappy.  Looks weird, as does %%.  Looks like a mess.

--
Eric Coleman


On Nov 26, 2005, at 7:17 PM, Jasper Bryant-Greene wrote:

David Zülke

20 years ago

If we rule out :::, it should be <- instead.

Foo:>bar:>Baz::getTest()->foo();

vs

Foo<-bar<-Baz::getTest()->foo();

The latter looks better to me. I'd still prefer

Foo:::bar:::Baz::getTest()->foo();

though.

- David

Am 27.11.2005 um 01:28 schrieb Eric Coleman:

Oliver Grätz

20 years ago

David Zülke schrieb:

> Foo:>bar:>Baz::getTest()->foo();
> Foo<-bar<-Baz::getTest()->foo();
> Foo:::bar:::Baz::getTest()->foo();

OK, for completeness:

Foo%%bar%%Baz::getTest()->foo();

Yes, it is blocky, as is the :: for class scopes.
But it's very clear to see where the namespaces are and where the
regular stuff is. Its blocky nature even comes as a plus here.

My second candidate would be

Foo:>bar:>Baz::getTest()->foo();

because ::: really seems to similar to the class scope operator (risk of
mixing the two) an "<-" seems to be ruled out by parser limitations (the
"-" is a unary prefix operator for anything on its right side).

OLLi

Mike Robinson

20 years ago

They all look horrible.
The idea of namespaces scrapped altogether is a good solution.  :)

Best,

Mike Robinson

David Zülke wrote:

Oliver Grätz

20 years ago

Jasper Bryant-Greene schrieb:

> Oliver Grätz wrote:
>
>>Oliver Grätz schrieb:
>>
>>>   :>    <::    <-    <:    ..
>>
>>Whoops, forgot to add "%%"
>>
>
>
> +1 for <- here. It makes namespace hierarchies resemble diagrams of the
> same hierarchies (like inheritance in UML). It also visually makes
> sense, isn't hard to type, and doesn't look like a smiley (like :> etc).

If Marcus is correct, then this won't work because of such cases:

define('a',2);
define('a',3);
if (a<-b) echo 'gotcha';

Sorry :-(

OLLi

Hartmut Holzgraefe

20 years ago

Jasper Bryant-Greene wrote:

> +1 for <- here. It makes namespace hierarchies resemble diagrams of the
> same hierarchies (like inheritance in UML). It also visually makes
> sense, isn't hard to type, and doesn't look like a smiley (like :> etc).

wouldn't that create an amiguity with

T_LESS_THAN T_UNARY_MINUS

like in

if (SOME_CONSTANT<-SOME_OTHER_CONSTANT)

so that we are back to the same problem we alread have with ':'?

--
Hartmut Holzgraefe, Senior Support Engineer                            .
MySQL AB, www.mysql.com

Oliver Grätz

20 years ago

Hartmut Holzgraefe schrieb:

> wouldn't that create an amiguity with
>
>    T_LESS_THAN T_UNARY_MINUS
>
> like in
>
>    if (SOME_CONSTANT<-SOME_OTHER_CONSTANT)
>
> so that we are back to the same problem we alread have with ':'?

Yes we do.
Congratulations, you are the 100th contributer stating that in this
thread. And this was clear BEFORE I opened it. Perhaps I should have
made it more clear that this is not only a search for POSSIBLE operator
symbols but for WANTED operator symbols. Anybody can say whatever he/she
wants. Sorting out comes later.

OLLi

Christian Stocker

20 years ago

On 27.11.2005 0:40 Uhr, Oliver Grätz wrote:

> Now some requirements:
>
> - needs to work without collisions in the parser
>   (seems to kill ":","::","->")
> - should be easily distinguishable from other, similar operators
>   (seems to kill ":::")
> - at least one person on earth should like it
>   (seems to kill "\")

Compared with the proposed smiley operators, please count me as the one
person who likes the \ operator ..


chregu

Stanislav Malyshev

20 years ago

MF>>Unless I'm missing something these symbols should not conflict with
MF>>other ones. They also have more a PHP "feel".

I wonder what "PHP feel" is in bunch of special symbols with meaning
entirely obscure to non-initiated... Why not {@ or <* then? They are nice
ASCII art too. And there are so many combinations of two special symbols,
let's find a meaning for all of them. Or at least for as many as we can.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Matthew Charles Kavanagh

20 years ago

On Sun, 2005-11-27 at 00:06 +0200, Stanislav Malyshev wrote:

> I wonder what "PHP feel" is in bunch of special symbols with meaning
> entirely obscure to non-initiated... Why not {@ or <* then? They are nice
> ASCII art too. And there are so many combinations of two special symbols,
> let's find a meaning for all of them. Or at least for as many as we can.

Great, everyone loves sarcasm, but you're describing exactly the
opposite of what's going on in this thread. There is a perceived need
for this functionality and you could argue for or against the
functionality instead. There's plenty of two character tokens in PHP
already and people aren't calling it "PerlHP" yet.

The -> suggestion if practicable seems the most intuitively correct to
me.

David Zülke

20 years ago

-> is crap because it is used for accessing object methods and
properties. Come on, guys. It is not that difficult. Think before you
write.

- David


Am 26.11.2005 um 23:16 schrieb Matthew C. Kavanagh:

Matthew Charles Kavanagh

20 years ago

Don't let the identifiers collide, then.

On Sat, 2005-11-26 at 23:23 +0100, David Zülke wrote:

David Zülke

20 years ago

The proposal is just stupid. It cannot get any more confusing and
inconsistent.


Am 26.11.2005 um 23:29 schrieb Matthew C. Kavanagh:

Roman Ivanov

20 years ago

David Zülke wrote:

> -> is crap because it is used for accessing object methods and
> properties.

BS. Java uses dot to separate everything, and it works perfectly fine.

Stanislav Malyshev

20 years ago

MCK>>The -> suggestion if practicable seems the most intuitively correct
MCK>>to me.

Yes, with one exception that this already has a meaning and it has nothing
to do with namespaces.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Marcus Börger

20 years ago

Hello Stanislav,

i know that language it is call ed PerlHyPer :-)

marcus

Saturday, November 26, 2005, 11:06:17 PM, you wrote:

MF>>>Unless I'm missing something these symbols should not conflict with
MF>>>other ones. They also have more a PHP "feel".

> I wonder what "PHP feel" is in bunch of special symbols with meaning
> entirely obscure to non-initiated... Why not {@ or <* then? They are nice
> ASCII art too. And there are so many combinations of two special symbols,
> let's find a meaning for all of them. Or at least for as many as we can.
> --
> Stanislav Malyshev, Zend Products Engineer
> stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Best regards,
Marcus

Marcus Börger

20 years ago

Hello Matt,

bla!

Saturday, November 26, 2005, 10:19:18 PM, you wrote:

> Hi, I've been following your conversations all day and think I might
> have a nice idea for the namespace separator idea. Sorry to barge in
> on your conversation but I think the following has value.

> What about something like <- or <:: or even just <:

> It makes sense to me because a namespace is akin to a parent of the
> class and in a diagram I would use an arrow to point to the parent
> from the child. At least there is some type of parent <- child
> relation.

> examples:
> Namespace <:: ClassName
> or
> Namespace <- ClassName
> or
> Namespace <: ClassName

> Unless I'm missing something these symbols should not conflict with
> other ones. They also have more a PHP "feel".

> This is the most semantically pleasing for me and it mirrors a common
> convention and represents the actual relationship. In the language it
> is nice when the symbols have an appearance representative of the
> actual relationship.

> When I see \ I think of ugly Windoze file paths. Also ::: seems awkward somehow.

> Matt.

> On 11/26/05, Jessie Hernandez <jrhernandez05@gmail.com> wrote:
>> I personally don't like any of these, but I just thought of this one:
>> "%%". Don't think it'll cause any problems at all, and look at the code:
>>
>> <?php
>> $a = new name1%%name2;
>> $b = name1::name2; // I see the difference clearly
>> ?>
>>
>>
>> What do you think? ":::" is more intuitive for me, but "%%" is an
>> acceptable alternative...
>>
>>
>> Regards,
>>
>> Jessie
>>
>>
>> Greg Beaver wrote:
>> > Hi all,
>> >
>> > I have only one caveat with the \ separator, which is that it is a
>> > little bit too similar to division with /, and can result in some
>> > confusing code like:
>> >
>> > <?php
>> > namespace name1 {
>> >     class name2{}
>> > }
>> > define('name1', 1);
>> > define('name2', 2);
>> >
>> > $a = new name1\name2;
>> > $b = name1/name2;
>> > ?>
>> >
>> > The same issue exists with all colon based separators (that sounds bad
>> > when read the wrong way...) because of the ternary operator, and :: with
>> > static classes/methods.
>> >
>> > <?php
>> > namespace name1 {
>> >     class name2{}
>> > }
>> > define('name1', 1);
>> > define('name2', 2);
>> > // this may be a parse error with the current namespace patch,
>> > // but need not be if we use ->
>> > class name1
>> > {
>> >     const name2 = 1;
>> > }
>> >
>> > $a = new name1:::name2;
>> > $b = name1::name2; // do you see the difference?  I get confused
>> > ?>
>> >
>> > What about using the T_OBJECT_OPERATOR?  This is a parse error in
>> > existing versions, and also implies some separation.
>> >
>> > <?php
>> > namespace name1 {
>> >     class name2{}
>> > }
>> > define('name1', 1);
>> > define('name2', 2);
>> > // this may be a parse error with the current namespace patch,
>> > // but need not be if we use ->
>> > class name1
>> > {
>> >     const name2 = 1;
>> > }
>> >
>> > $a = new name1->name2;
>> > $b = name1::name2;
>> > ?>
>> >
>> > I also proposed on IRC using \\ as this is similar to netware driver
>> > separators:
>> >
>> > <?php
>> > define('name1', 1);
>> > define('name2', 2);
>> >
>> > $a = new name1\\name2;
>> > $b = name1/name2;
>> > ?>
>> >
>> > However, I know Andrei hated this :).  I very much prefer the use of ->,
>> > as this has the same advantage as :: of "rhyming" with current syntax.
>> >
>> > Greg
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

> --
> -- Matt Friedman

> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

Best regards,
Marcus

Jessie Hernandez

20 years ago

Marcus Boerger wrote:

> Hello Matt,
>
>   bla!
>

LOL!

--
Jessie

Lorenzo Alberton

20 years ago

Matt Friedman wrote:

> Namespace <:: ClassName
> or
> Namespace <- ClassName
> or
> Namespace <: ClassName
>
> Unless I'm missing something these symbols should not conflict with
> other ones.

I'm not sure if someone already mentioned it,
but "<-" is not acceptable, since it means
"less than the opposite of"

==============================
<?php
define ('a', 1);
define ('b', 0);

$c = (b<-a);
//i.e.  $c = (b < -a)
?>
==============================

Regards,

--
Lorenzo Alberton
http://pear.php.net/user/quipo

Nicolas Bérard Nault

20 years ago

Hadn't thought about that one... Thank you for the comment.

I now think '\' is the best choice.

On 11/27/05, Lorenzo Alberton <l.alberton@quipo.it> wrote:

>
> Matt Friedman wrote:
> > Namespace <:: ClassName
> > or
> > Namespace <- ClassName
> > or
> > Namespace <: ClassName
> >
> > Unless I'm missing something these symbols should not conflict with
> > other ones.
>
> I'm not sure if someone already mentioned it,
> but "<-" is not acceptable, since it means
> "less than the opposite of"
>
> ==============================
> <?php
> define ('a', 1);
> define ('b', 0);
>
> $c = (b<-a);
> //i.e.  $c = (b < -a)
> ?>
> ==============================
>
> Regards,
> --
> Lorenzo Alberton
> http://pear.php.net/user/quipo
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Nicolas Bérard Nault (nicobn@gmail.com)
"Maybe nature is fundamentally ugly, chaotic and complicated. But if it's
like that, then I want out." -- Steven Weinberg (prix Nobel de physique,
1979).

Jared Williams

20 years ago

> Hi all,
>
> I have only one caveat with the \ separator, which is that it
> is a little bit too similar to division with /, and can
> result in some confusing code like:
>
> <?php
> namespace name1 {
>     class name2{}
> }
> define('name1', 1);
> define('name2', 2);
>
> $a = new name1\name2;
> $b = name1/name2;
> ?>
>
> The same issue exists with all colon based separators (that
> sounds bad when read the wrong way...) because of the ternary
> operator, and :: with static classes/methods.
>
> <?php
> namespace name1 {
>     class name2{}
> }
> define('name1', 1);
> define('name2', 2);
> // this may be a parse error with the current namespace
> patch, // but need not be if we use -> class name1 {
>     const name2 = 1;
> }
>
> $a = new name1:::name2;
> $b = name1::name2; // do you see the difference?  I get confused ?>
>
> What about using the T_OBJECT_OPERATOR?  This is a parse
> error in existing versions, and also implies some separation.
>
> <?php
> namespace name1 {
>     class name2{}
> }
> define('name1', 1);
> define('name2', 2);
> // this may be a parse error with the current namespace
> patch, // but need not be if we use -> class name1 {
>     const name2 = 1;
> }
>
> $a = new name1->name2;
> $b = name1::name2;
> ?>
>
> I also proposed on IRC using \\ as this is similar to netware driver
> separators:
>
> <?php
> define('name1', 1);
> define('name2', 2);
>
> $a = new name1\\name2;
> $b = name1/name2;
> ?>
>
> However, I know Andrei hated this :).  I very much prefer the
> use of ->, as this has the same advantage as :: of "rhyming"
> with current syntax.

Hi,
I was thinking -> too.. Had ideas of namespaces being object instances in their own right..

namespace foo { const ACONST = '1'; class bar {} }

echo $foo->bar;			// some mangled internal class name (foo_bar_123 or something) to make it unique
$a = new $foo->bar();
$ref = new ReflectionClass($foo->bar);

Jared

Jason Garber

20 years ago

Hello,

I as a userland library author, would appreciate namespaces quite a
bit.  Here is an idea:

namespace1..class()

$x = new MyApp..MemberOrder();

--
Best regards,
Jason                            mailto:jason@ionzoft.com

Saturday, November 26, 2005, 3:52:35 PM, you wrote:

GB> Hi all,

GB> I have only one caveat with the \ separator, which is that it is a
GB> little bit too similar to division with /, and can result in some
GB> confusing code like:

GB> <?php
GB> namespace name1 {
GB>     class name2{}
GB> }
GB> define('name1', 1);
GB> define('name2', 2);

GB> $a = new name1\name2;
GB> $b = name1/name2;
?>>

GB> The same issue exists with all colon based separators (that sounds bad
GB> when read the wrong way...) because of the ternary operator, and :: with
GB> static classes/methods.

GB> <?php
GB> namespace name1 {
GB>     class name2{}
GB> }
GB> define('name1', 1);
GB> define('name2', 2);
GB> // this may be a parse error with the current namespace patch,
GB> // but need not be if we use ->
GB> class name1
GB> {
GB>     const name2 = 1;
GB> }

GB> $a = new name1:::name2;
GB> $b = name1::name2; // do you see the difference?  I get confused
?>>

GB> What about using the T_OBJECT_OPERATOR?  This is a parse error in
GB> existing versions, and also implies some separation.

GB> <?php
GB> namespace name1 {
GB>     class name2{}
GB> }
GB> define('name1', 1);
GB> define('name2', 2);
GB> // this may be a parse error with the current namespace patch,
GB> // but need not be if we use ->
GB> class name1
GB> {
GB>     const name2 = 1;
GB> }

$a = new name1->>name2;
GB> $b = name1::name2;
?>>

GB> I also proposed on IRC using \\ as this is similar to netware driver
GB> separators:

GB> <?php
GB> define('name1', 1);
GB> define('name2', 2);

GB> $a = new name1\\name2;
GB> $b = name1/name2;
?>>

GB> However, I know Andrei hated this :).  I very much prefer the use of ->,
GB> as this has the same advantage as :: of "rhyming" with current syntax.

GB> Greg

Oliver Grätz

20 years ago

OK, you requested for it! *g*

OLLi

Jessie Hernandez

20 years ago

Great work, Oliver! I personally also add a +1 for ":", with the
whitespace restriction in the ternary operator (or just removing
namespace constants).

I would also add another restriction: you cannot more than one point
for/against (so no +2's or -2's, etc.). It just doesn't make sense (I
might as well do +4000000 for whatever I want :-) ).

Regards,

Jessie

Oliver Grätz wrote:

Oliver Grätz

20 years ago

OK, I'll update the table. One moment...
I leave the +2 in and have added a -2 , which I didn't use as I didn't
want to pre-vote anyones comments so clearly. There should be 5 non-zero
values (as in ++/+/o/-/--, which is used in project-portfolio-planning),
as one can put some weighting into the answer. I suppose there won't be
anyone truely judging by this table but I clearly lost the overview so
this is a way of ruling out some candidates.

OLLi

Nicolas Bérard Nault

20 years ago

+2 to <-, which, in my humble opinion, is more logic than anything else that
was proposed (as mentionned earlier, it creates a sort of "hierachy").

\ and %% just seem too extravagant... -2 to them I guess.

Just my 2 cents.

On 11/26/05, Oliver Grätz <oliver.graetz@arcor.de> wrote:

>
> OK, I'll update the table. One moment...
> I leave the +2 in and have added a -2 , which I didn't use as I didn't
> want to pre-vote anyones comments so clearly. There should be 5 non-zero
> values (as in ++/+/o/-/--, which is used in project-portfolio-planning),
> as one can put some weighting into the answer. I suppose there won't be
> anyone truely judging by this table but I clearly lost the overview so
> this is a way of ruling out some candidates.
>
> OLLi
>
>
>
> First update:
>
> Namespace Operators
>
> ========================================================================================================================
> Name                 |s| %%  | :   | ::: | ::< | :<  | <-  | :>  | \   |
> ->  | \\  | <:: | <:  | ..  |     |     |     |
>
> ---------------------+-+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
> Robert Deaton        |-| +0  |     | -1  |     |     | -2  | +1  |
> |     |     |     |     |     |     |     |     |
> Alan Knowles         |-|     | +1  |     |     |     |     |     |
> |     |     |     |     |     |     |     |     |
> Greg Beaver          |-|     | +0  | +0  | +0  | +0  |     | +0  | +0  |
> +1  | +1  | +0  | +0  |     |     |     |     |
> Jessie Hernandez     |-| +1  | +1  | +2  |     |     |     |     |
> |     |     |     |     |     |     |     |     |
> Matt Friedman        |-|     |     | -1  |     |     | +1  |     |
> -1  |     |     | +1  | +1  |     |     |     |     |
> David Zülke          |-|     |     | +2  |     |     | +1  | -1  |
> |     |     |     | -1  |     |     |     |     |
> Oliver Grätz         |*| +2  |     | +1  |     |     |     |     |
> |     |     |     |     |     |     |     |     |
> Matthew C. Kavanagh  |-| -1  |     |     |     |     |     |     |
> |     |     |     |     |     |     |     |     |
> Jasper Bryant-Greene |-|     |     |     |     | -1  | +1  | -1  |
> |     |     |     | -1  |     |     |     |     |
> Eric Coleman         |-| -1  |     |     |     |     | +1  | +1  |
> -1  |     |     |     |     |     |     |     |     |
> Christian Stocker    |-|     |     |     |     | -1  |     | -1  |
> +1  |     |     |     | -1  |     |     |     |     |
> Stanislav Malyshev   |-|     |     |     |     |     |     |     |
> |     |     |     |     |     |     |     |     |
> Jared Williams       |-|     |     |     |     |     |     |     |     |
> +1  |     |     |     |     |     |     |     |
> Jason Garber         | |     |     |     |     |     |     |     |
> |     |     |     |     | +1  |     |     |     |
>                      | |     |     |     |     |     |     |     |
> |     |     |     |     |     |     |     |     |
>
> ---------------------+-+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
> sum                  | | +1  | +1  | +3  | +0  | -2  | +2  | -1  | -1  |
> +2  | +1  | +1  | -2  | +1  |     |     |     |
>
> ========================================================================================================================
>
> Notes:
> - I took
>   +2 as "likes"
>   +1 as "is fine with"
>   +0 as "can live with"
>   -1 as "dislikes"
>   -2 as "hates"
>   empty for "no comment, no opinion, don't care"
> - Please don't enter anything other than these values!
> - The "s" column stands for "self-filled". I compiled the current
>   table from the comments in this newsgroup, so perhaps I didn't
>   get their comments right.
> - The operators : <- -> could make big problems with the parser.
>   More complaints to follow. *g*
> - Feel free to add new suggestions to the right.
> - If you add your name at the bottom, please copy the free line
>   so the next one also has a free one.
> - Do only edit the votes in *your* line!
> - Correct the sums if you post.
> - Please post as attachment!
>
> If some of the operators are definitely impossible to implement,
> please put the headline of column in parentheses (as in "(<-)")
> ans add a note why this operator can't be done (Hi Marcus *g*).
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Nicolas Bérard Nault (nicobn@gmail.com)
"Maybe nature is fundamentally ugly, chaotic and complicated. But if it's
like that, then I want out." -- Steven Weinberg (prix Nobel de physique,
1979).

Matthew Charles Kavanagh

20 years ago

On Sat, 2005-11-26 at 21:41 -0500, Nicolas Bérard Nault wrote:

> +2 to <-, which, in my humble opinion, is more logic than anything else that
> was proposed (as mentionned earlier, it creates a sort of "hierachy").

Hmm, is it really necessary to vote for separators which aren't remotely
technically possible and have been pointed out as such? ;)

Sara Golemon

20 years ago

For the record, I vote for :::
T_מְשֻׁלָּשׁ_NEKUDOTAYIM
(Sorry, couldn't find a transliteration of "triple")

-Sara

Jessie Hernandez

20 years ago

Hi Sara,

Sara Golemon wrote:

> For the record, I vote for :::
> T_מְשֻׁלָּשׁ_NEKUDOTAYIM
> (Sorry, couldn't find a transliteration of "triple")
>
> -Sara
>

I'll call it T_JESSIEYIM_NEKUDONAMESPACE ;-) !

Regards,

Jessie

Jacques Marneweck

20 years ago

Sara Golemon wrote:

> For the record, I vote for :::
> T_מְשֻׁלָּשׁ_NEKUDOTAYIM
> (Sorry, couldn't find a transliteration of "triple")
>

Sean reckons that it's Shaloshayim
(http://blog.phpdoc.info/archives/27-+1-for-Shaloshayim-Nekudotayim.html):

T_SHALOSHAYIM_NEKUDOTAYIM

Regards
--jm

> -Sara
>
>> OK, I'll update the table. One moment...
>> I leave the +2 in and have added a -2 , which I didn't use as I didn't
>> want to pre-vote anyones comments so clearly. There should be 5 non-zero
>> values (as in ++/+/o/-/--, which is used in project-portfolio-planning),
>> as one can put some weighting into the answer. I suppose there won't be
>> anyone truely judging by this table but I clearly lost the overview so
>> this is a way of ruling out some candidates.
>>
>> OLLi
>>
>>
>
>
>
>> First update:
>>
>> Namespace Operators
>> ========================================================================================================================
>>
>> Name                 |s| %%  | :   | ::: | ::< | :<  | <-  | :>  | \
>>   | ->  | \\  | <:: | <:  | ..  |     |     |     |
>> ---------------------+-+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
>>
>> Robert Deaton        |-| +0  |     | -1  |     |     | -2  | +1
>> |     | |     |     |     |     |     |     |     |
>> Alan Knowles         |-|     | +1  |     |     |     |     |
>> |     | |     |     |     |     |     |     |     |
>> Greg Beaver          |-|     | +0  | +0  | +0  | +0  |     | +0  |
>> +0  | +1  | +1  | +0  | +0  |     |     |     |     |
>> Jessie Hernandez     |-| +1  | +1  | +2  |     |     |     |
>> |     | |     |     |     |     |     |     |     |
>> Matt Friedman        |-|     |     | -1  |     |     | +1  |     |
>> -1  | |     | +1  | +1  |     |     |     |     |
>> David Zülke          |-|     |     | +2  |     |     | +1  | -1
>> |     | |     |     | -1  |     |     |     |     |
>> Oliver Grätz         |*| +2  |     | +1  |     |     |     |
>> |     | |     |     |     |     |     |     |     |
>> Matthew C. Kavanagh  |-| -1  |     |     |     |     |     |
>> |     | |     |     |     |     |     |     |     |
>> Jasper Bryant-Greene |-|     |     |     |     | -1  | +1  | -1
>> |     | |     |     | -1  |     |     |     |     |
>> Eric Coleman         |-| -1  |     |     |     |     | +1  | +1  |
>> -1  | |     |     |     |     |     |     |     |
>> Christian Stocker    |-|     |     |     |     | -1  |     | -1  |
>> +1  | |     |     | -1  |     |     |     |     |
>> Stanislav Malyshev   |-|     |     |     |     |     |     |
>> |     | |     |     |     |     |     |     |     |
>> Jared Williams       |-|     |     |     |     |     |     |
>> |     | +1  |     |     |     |     |     |     |     |
>> Jason Garber         | |     |     |     |     |     |     |
>> |     | |     |     |     | +1  |     |     |     |
>>                     | |     |     |     |     |     |     |     |
>> | |     |     |     |     |     |     |     |
>> ---------------------+-+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
>>
>> sum                  | | +1  | +1  | +3  | +0  | -2  | +2  | -1  |
>> -1  | +2  | +1  | +1  | -2  | +1  |     |     |     |
>> ========================================================================================================================
>>
>>
>> Notes:
>> - I took
>>  +2 as "likes"
>>  +1 as "is fine with"
>>  +0 as "can live with"
>>  -1 as "dislikes"
>>  -2 as "hates"
>>  empty for "no comment, no opinion, don't care"
>> - Please don't enter anything other than these values!
>> - The "s" column stands for "self-filled". I compiled the current
>>  table from the comments in this newsgroup, so perhaps I didn't
>>  get their comments right.
>> - The operators : <- -> could make big problems with the parser.
>>  More complaints to follow. *g*
>> - Feel free to add new suggestions to the right.
>> - If you add your name at the bottom, please copy the free line
>>  so the next one also has a free one.
>> - Do only edit the votes in *your* line!
>> - Correct the sums if you post.
>> - Please post as attachment!
>>
>> If some of the operators are definitely impossible to implement,
>> please put the headline of column in parentheses (as in "(<-)")
>> ans add a note why this operator can't be done (Hi Marcus *g*).
>>
>

--
Jacques Marneweck
http://www.powertrip.co.za/blog/

Marcus Börger

20 years ago

Hello Jacques,

can we name it T_WTF_COLON

Sunday, November 27, 2005, 12:05:19 PM, you wrote:

> Sara Golemon wrote:
>> For the record, I vote for :::
>> T_??????????_NEKUDOTAYIM
>> (Sorry, couldn't find a transliteration of "triple")
>>
> Sean reckons that it's Shaloshayim
> (http://blog.phpdoc.info/archives/27-+1-for-Shaloshayim-Nekudotayim.html):

> T_SHALOSHAYIM_NEKUDOTAYIM

> Regards
> --jm
>> -Sara
>>
>>> OK, I'll update the table. One moment...
>>> I leave the +2 in and have added a -2 , which I didn't use as I didn't
>>> want to pre-vote anyones comments so clearly. There should be 5 non-zero
>>> values (as in ++/+/o/-/--, which is used in project-portfolio-planning),
>>> as one can put some weighting into the answer. I suppose there won't be
>>> anyone truely judging by this table but I clearly lost the overview so
>>> this is a way of ruling out some candidates.
>>>
>>> OLLi
>>>
>>>
>>
>>
>>
>>> First update:
>>>
>>> Namespace Operators
>>> ========================================================================================================================
>>>
>>> Name                 |s| %%  | :   | ::: | ::< | :<  | <-  | :>  | \
>>>   | ->  | \\  | <:: | <:  | ..  |     |     |     |
>>> ---------------------+-+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
>>>
>>> Robert Deaton        |-| +0  |     | -1  |     |     | -2  | +1
>>> |     | |     |     |     |     |     |     |     |
>>> Alan Knowles         |-|     | +1  |     |     |     |     |
>>> |     | |     |     |     |     |     |     |     |
>>> Greg Beaver          |-|     | +0  | +0  | +0  | +0  |     | +0  |
>>> +0  | +1  | +1  | +0  | +0  |     |     |     |     |
>>> Jessie Hernandez     |-| +1  | +1  | +2  |     |     |     |
>>> |     | |     |     |     |     |     |     |     |
>>> Matt Friedman        |-|     |     | -1  |     |     | +1  |     |
>>> -1  | |     | +1  | +1  |     |     |     |     |
>>> David Zülke          |-|     |     | +2  |     |     | +1  | -1
>>> |     | |     |     | -1  |     |     |     |     |
>>> Oliver Grätz         |*| +2  |     | +1  |     |     |     |
>>> |     | |     |     |     |     |     |     |     |
>>> Matthew C. Kavanagh  |-| -1  |     |     |     |     |     |
>>> |     | |     |     |     |     |     |     |     |
>>> Jasper Bryant-Greene |-|     |     |     |     | -1  | +1  | -1
>>> |     | |     |     | -1  |     |     |     |     |
>>> Eric Coleman         |-| -1  |     |     |     |     | +1  | +1  |
>>> -1  | |     |     |     |     |     |     |     |
>>> Christian Stocker    |-|     |     |     |     | -1  |     | -1  |
>>> +1  | |     |     | -1  |     |     |     |     |
>>> Stanislav Malyshev   |-|     |     |     |     |     |     |
>>> |     | |     |     |     |     |     |     |     |
>>> Jared Williams       |-|     |     |     |     |     |     |
>>> |     | +1  |     |     |     |     |     |     |     |
>>> Jason Garber         | |     |     |     |     |     |     |
>>> |     | |     |     |     | +1  |     |     |     |
>>>                     | |     |     |     |     |     |     |     |
>>> | |     |     |     |     |     |     |     |
>>> ---------------------+-+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
>>>
>>> sum                  | | +1  | +1  | +3  | +0  | -2  | +2  | -1  |
>>> -1  | +2  | +1  | +1  | -2  | +1  |     |     |     |
>>> ========================================================================================================================
>>>
>>>
>>> Notes:
>>> - I took
>>>  +2 as "likes"
>>>  +1 as "is fine with"
>>>  +0 as "can live with"
>>>  -1 as "dislikes"
>>>  -2 as "hates"
>>>  empty for "no comment, no opinion, don't care"
>>> - Please don't enter anything other than these values!
>>> - The "s" column stands for "self-filled". I compiled the current
>>>  table from the comments in this newsgroup, so perhaps I didn't
>>>  get their comments right.
>>> - The operators : <- -> could make big problems with the parser.
>>>  More complaints to follow. *g*
>>> - Feel free to add new suggestions to the right.
>>> - If you add your name at the bottom, please copy the free line
>>>  so the next one also has a free one.
>>> - Do only edit the votes in *your* line!
>>> - Correct the sums if you post.
>>> - Please post as attachment!
>>>
>>> If some of the operators are definitely impossible to implement,
>>> please put the headline of column in parentheses (as in "(<-)")
>>> ans add a note why this operator can't be done (Hi Marcus *g*).
>>>
>>

> --
> Jacques Marneweck
> http://www.powertrip.co.za/blog/

Best regards,
Marcus

Sean Coates

20 years ago

> Sean reckons that it's Shaloshayim
> (http://blog.phpdoc.info/archives/27-+1-for-Shaloshayim-Nekudotayim.html):
>
> T_SHALOSHAYIM_NEKUDOTAYIM

Changed that to Shalosh (as apparently the -ayim means "twice" (as in
PAAM=2, AYIM=twice, NEKUDOT=dot, AYIM=twice)).

Not that I claim to know very much about Hebrew...

(and it was mostly a joke, but I would like to see ::: if \ is so bad)

S

Stanislav Malyshev

20 years ago

SC>>Changed that to Shalosh (as apparently the -ayim means "twice" (as in
SC>>PAAM=2, AYIM=twice, NEKUDOT=dot, AYIM=twice)).

PAAM actually means "once" :)

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Eric Coleman

20 years ago

If : is still a viable solution, i'd much rather see that used :P

-- Eric

--
Eric Coleman

On Nov 26, 2005, at 9:21 PM, Jessie Hernandez wrote:

Matt Friedman

20 years ago

Could I kindly get the grid as an attachment? Gmail messed up the formatting.

On 11/26/05, Eric Coleman <eric@aplosmedia.com> wrote:

> If : is still a viable solution, i'd much rather see that used :P
>
> -- Eric
> --
> Eric Coleman
>
> On Nov 26, 2005, at 9:21 PM, Jessie Hernandez wrote:
>
> > Great work, Oliver! I personally also add a +1 for ":", with the
> > whitespace restriction in the ternary operator (or just removing
> > namespace constants).
> >
> > I would also add another restriction: you cannot more than one
> > point for/against (so no +2's or -2's, etc.). It just doesn't make
> > sense (I might as well do +4000000 for whatever I want :-) ).
> >
> >
> > Regards,
> >
> > Jessie
> >
> >
> >
> > Oliver Grätz wrote:
> >> OK, you requested for it! *g*
> >> OLLi
> >> ---------------------------------------------------------------------
> >> ---
> >> Namespace Operators
> >> =====================================================================
> >> ===================================================
> >> Name                 |s| %%  | :   | ::: | ::< | :<  | <-  | :>  |
> >> \   | ->  | \\  | <:: | <:  | ..  |     |     |     |
> >> ---------------------+-+-----+-----+-----+-----+-----+-----+-----
> >> +-----+-----+-----+-----+-----+-----+-----+-----+-----+
> >> Robert Deaton        |-| +0  |     | -1  |     |     | -2  | +1
> >> |     |     |     |     |     |     |     |     |     | Alan
> >> Knowles         |-|     | +1  |     |     |     |     |     |
> >> |     |     |     |     |     |     |     |     |
> >> Greg Beaver          |-|     | +0  | +0  | +0  | +0  |     | +0  |
> >> +0  | +1  | +1  | +0  | +0  |     |     |     |     |
> >> Jessie Hernandez     |-| +1  |     | +2  |     |     |     |
> >> |     |     |     |     |     |     |     |     |     |
> >> Matt Friedman        |-|     |     | -1  |     |     | +1  |     |
> >> -1  |     |     | +1  | +1  |     |     |     |     |
> >> David Zülke          |-|     |     | +2  |     |     | +1  | -1
> >> |     |     |     |     | -1  |     |     |     |     |
> >> Oliver Grätz         |*| +2  |     | +1  |     |     |     |
> >> |     |     |     |     |     |     |     |     |     |
> >> Matthew C. Kavanagh  |-| -1  |     |     |     |     |     |
> >> |     |     |     |     |     |     |     |     |     |
> >> Jasper Bryant-Greene |-|     |     |     |     | -1  | +1  | -1
> >> |     |     |     |     | -1  |     |     |     |     |
> >> Eric Coleman         |-| -1  |     |     |     |     | +1  | +1  |
> >> -1  |     |     |     |     |     |     |     |     |
> >> Christian Stocker    |-|     |     |     |     | -1  |     | -1  |
> >> +1  |     |     |     | -1  |     |     |     |     |
> >> Stanislav Malyshev   |-|     |     |     |     |     |     |
> >> |     |     |     |     |     |     |     |     |     |
> >> Jared Williams       |-|     |     |     |     |     |     |
> >> |     | +1  |     |     |     |     |     |     |     |
> >> Jason Garber         | |     |     |     |     |     |     |
> >> |     |     |     |     |     | +1  |     |     |     |
> >>                      | |     |     |     |     |     |     |
> >> |     |     |     |     |     |     |     |     |     |
> >> ---------------------+-+-----+-----+-----+-----+-----+-----+-----
> >> +-----+-----+-----+-----+-----+-----+-----+-----+-----+
> >> sum                  | | +1  | +1  | +3  | +0  | -2  | +2  | -1  |
> >> -1  | +2  | +1  | +1  | -2  | +1  |     |     |     |
> >> =====================================================================
> >> ===================================================
> >> Notes:
> >> - I took
> >>   +2 as "likes"
> >>   +1 as "is fine with"
> >>   +0 as "can live with"
> >>   -1 as "dislikes"
> >> - The "s" column stands for "self-filled". I compiled the current
> >>   table from the comments in this newsgroup, so perhaps I didn't
> >>   get their comments right. - The operators : <- -> could make big
> >> problems with the parser.
> >>   More complaints to follow. *g*
> >> - Feel free to add new suggestions to the right.
> >> - If you add your name at the bottom, please copy the free line
> >>   so the next one also has a free one.
> >> - Do only edit the votes in *your* line!
> >> - Correct the sums if you post.
> >> - Please post as attachment!
> >> If some of the operators are definitely impossible to implement,
> >> please put the headline of column in parentheses (as in "(<-)")
> >> ans add a note why this operator can't be done (Hi Marcus *g*).
> >
> > Namespace Operators
> > ======================================================================
> > ==================================================
> > Name                 |s| %%  | :   | ::: | ::< | :<  | <-  | :>  |
> > \   | ->  | \\  | <:: | <:  | ..  |     |     |     |
> > ---------------------+-+-----+-----+-----+-----+-----+-----+-----
> > +-----+-----+-----+-----+-----+-----+-----+-----+-----+
> > Robert Deaton        |-| +0  |     | -1  |     |     | -2  | +1
> > |     |     |     |     |     |     |     |     |     |
> > Alan Knowles         |-|     | +1  |     |     |     |     |
> > |     |     |     |     |     |     |     |     |     |
> > Greg Beaver          |-|     | +0  | +0  | +0  | +0  |     | +0  |
> > +0  | +1  | +1  | +0  | +0  |     |     |     |     |
> > Jessie Hernandez     |-| +1  | +1  | +1  |     |     |     |
> > |     |     |     |     |     |     |     |     |     |
> > Matt Friedman        |-|     |     | -1  |     |     | +1  |     |
> > -1  |     |     | +1  | +1  |     |     |     |     |
> > David Zülke          |-|     |     | +2  |     |     | +1  | -1
> > |     |     |     |     | -1  |     |     |     |     |
> > Oliver Grätz         |*| +2  |     | +1  |     |     |     |
> > |     |     |     |     |     |     |     |     |     |
> > Matthew C. Kavanagh  |-| -1  |     |     |     |     |     |
> > |     |     |     |     |     |     |     |     |     |
> > Jasper Bryant-Greene |-|     |     |     |     | -1  | +1  | -1
> > |     |     |     |     | -1  |     |     |     |     |
> > Eric Coleman         |-| -1  |     |     |     |     | +1  | +1  |
> > -1  |     |     |     |     |     |     |     |     |
> > Christian Stocker    |-|     |     |     |     | -1  |     | -1  |
> > +1  |     |     |     | -1  |     |     |     |     |
> > Stanislav Malyshev   |-|     |     |     |     |     |     |
> > |     |     |     |     |     |     |     |     |     |
> > Jared Williams       |-|     |     |     |     |     |     |
> > |     | +1  |     |     |     |     |     |     |     |
> > Jason Garber         | |     |     |     |     |     |     |
> > |     |     |     |     |     | +1  |     |     |     |
> >                      | |     |     |     |     |     |     |
> > |     |     |     |     |     |     |     |     |     |
> > ---------------------+-+-----+-----+-----+-----+-----+-----+-----
> > +-----+-----+-----+-----+-----+-----+-----+-----+-----+
> > sum                  | | +1  | +1  | +3  | +0  | -2  | +2  | -1  |
> > -1  | +2  | +1  | +1  | -2  | +1  |     |     |     |
> > ======================================================================
> > ==================================================
> >
> > --
> > 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
>
>

--
-- Matt Friedman

Jessie Hernandez

20 years ago

Sorry, did not notice you put a special meaning to +2, +1, etc. You can
put a +2 for me for ":" and a +1 for ":::".

Anyways, I'm tired of discussing this. I'm going to stick to ::: for
now, and if constants are not wanted, I'll then go with ":". I have to
work on some minor details of the patch, which are more important than
this (I put the namespace separator in a #define, so it can easily be
changed in the future).


Regards,

Jessie


Jessie Hernandez wrote:

Jacques Marneweck

20 years ago

Oliver Grätz wrote:

> OK, you requested for it! *g*
>
> OLLi
>
> ------------------------------------------------------------------------
>
>
> Namespace Operators
> ========================================================================================================================
> Name                 |s| %%  | :   | ::: | ::< | :<  | <-  | :>  | \   | ->  | \\  | <:: | <:  | ..  |     |     |     |
> ---------------------+-+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
> Robert Deaton        |-| +0  |     | -1  |     |     | -2  | +1  |     |     |     |     |     |     |     |     |     |
> Alan Knowles         |-|     | +1  |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
> Greg Beaver          |-|     | +0  | +0  | +0  | +0  |     | +0  | +0  | +1  | +1  | +0  | +0  |     |     |     |     |
> Jessie Hernandez     |-| +1  |     | +2  |     |     |     |     |     |     |     |     |     |     |     |     |     |
> Matt Friedman        |-|     |     | -1  |     |     | +1  |     | -1  |     |     | +1  | +1  |     |     |     |     |
> David Zülke          |-|     |     | +2  |     |     | +1  | -1  |     |     |     |     | -1  |     |     |     |     |
> Oliver Grätz         |*| +2  |     | +1  |     |     |     |     |     |     |     |     |     |     |     |     |     |
> Matthew C. Kavanagh  |-| -1  |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
> Jasper Bryant-Greene |-|     |     |     |     | -1  | +1  | -1  |     |     |     |     | -1  |     |     |     |     |
> Eric Coleman         |-| -1  |     |     |     |     | +1  | +1  | -1  |     |     |     |     |     |     |     |     |
> Christian Stocker    |-|     |     |     |     | -1  |     | -1  | +1  |     |     |     | -1  |     |     |     |     |
> Stanislav Malyshev   |-|     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
> Jared Williams       |-|     |     |     |     |     |     |     |     | +1  |     |     |     |     |     |     |     |
> Jason Garber         | |     |     |     |     |     |     |     |     |     |     |     |     | +1  |     |     |     |
> Jacques Marneweck    | | -1  | -1  | +2  | -1  | -1  | -1  | -1  | -1  | -1  | +0  | -1  | -1  | +0  |     |     |     |
>                      | |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
> ---------------------+-+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
> sum                  | | +1  | +1  | +3  | +0  | -2  | +2  | -1  | -1  | +2  | +1  | +1  | -2  | +1  |     |     |     |
> ========================================================================================================================
>
> Notes:
> - I took
>   +2 as "likes"
>   +1 as "is fine with"
>   +0 as "can live with"
>   -1 as "dislikes"
> - The "s" column stands for "self-filled". I compiled the current
>   table from the comments in this newsgroup, so perhaps I didn't
>   get their comments right.
> - The operators : <- -> could make big problems with the parser.
>   More complaints to follow. *g*
> - Feel free to add new suggestions to the right.
> - If you add your name at the bottom, please copy the free line
>   so the next one also has a free one.
> - Do only edit the votes in *your* line!
> - Correct the sums if you post.
> - Please post as attachment!
>
> If some of the operators are definitely impossible to implement,
> please put the headline of column in parentheses (as in "(<-)")
> ans add a note why this operator can't be done (Hi Marcus *g*).
>
>

--
Jacques Marneweck
http://www.powertrip.co.za/blog/

Roman Ivanov

20 years ago

I hate the idea of voting for features, but since it might have some
affect on the language, I will add my opinion to the heap.

::: - Bad, because it's three characters.
: - Good, because it's one character, and it does not look like
something else.
\ - It's one character, but it looks like division/escape sequence.
Plus, it will raise syntactic hell in some editors.

Radical idea:
1) Use :.
2) Make : to work like ::.
3) Make : to work like ->.
4) But no one will agree to it anyway, so I stop here.

Oliver Grätz

20 years ago

Roman Ivanov schrieb:

> Radical idea:
> 1) Use :.
> 2) Make : to work like ::.
> 3) Make : to work like ->.
> 4) But no one will agree to it anyway, so I stop here.

Nope. I agree ;-)
But that train has already left.
(although I still think : could be made to work for the namespaces)

OLLi

Jessie Hernandez

20 years ago

Oliver,

Like I mentioned in another thread, ":" cannot be used, even if only
classes are allowed in namespaces. Look at this example:

$x = $y?a:b::c();

The above can be parsed either as the first argument being "the result
of method c of class b in namespace a" or the first argument being "the
define named 'a' if true and the result of method c of the
_unnamespaced_ class b". The only way to disambiguate is to force
whitespace or force parentheses usage, but this would make the language
inconsistent and confusing.


Regards,

Jessie

Oliver Grätz wrote:

Bart de Boer

20 years ago

What was the argument against '::' again?

Jessie Hernandez wrote:

Bart de Boer

20 years ago

Bart de Boer wrote:

> What was the argument against '::' again?
>
> Jessie Hernandez wrote:

Found it...

<snip from Jessie>

BTW, "::" is out the question (yes, I did try it). It created ambiguity
in the case of calling a function in a namespace and calling a method of
a class in a namespace:

echo a::b::c();

The above can either mean "call function c in namespace b under
namespace a" or "call static method c of class b under namespace a".
Since this cannot be determined, "::" cannot be used.

</snip from Jessie>

Lukas Smith

20 years ago

Hi,

not sure if phpnamespaces.org is a wise choice for a site that publishes
prepatched versions of php (see the php license) ..

it seems like there is a mailinglist there. while obviously the
namespace topic also relates to this list, I think it would be a good
idea if people not in tune with core hit this list with their ideas first.

it might also be a good idea to move all the separator ideas there along
with the reasons why this separator is or is not a wise choice.

so all in all this seems like a good way to increase the signal ratio on
this list ...

regards,
Lukas

Oliver Grätz

20 years ago

Lukas Smith schrieb:

> not sure if phpnamespaces.org is a wise choice for a site that publishes
> prepatched versions of php (see the php license) ..

If I read the mails there correctly this issue is already being worked upon.

> it seems like there is a mailinglist there. while obviously the
> namespace topic also relates to this list, I think it would be a good
> idea if people not in tune with core hit this list with their ideas first.
>
> it might also be a good idea to move all the separator ideas there along
> with the reasons why this separator is or is not a wise choice.

Didn't think of this. Yeah, probably a good idea. I'll switch now.


Saying ggod bye to seperator discussions here,
OLLi

Stanislav Malyshev

20 years ago

BdB>>The above can either mean "call function c in namespace b under
BdB>>namespace a" or "call static method c of class b under namespace a".
BdB>>Since this cannot be determined, "::" cannot be used.

This provided we support nested namespaces. Do we need them?

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Bart de Boer

20 years ago

Furthermore. The problem with echo 'a::b::c();' would only
occur if the code structure would be like this:

namespace a {
namespace b {
function c() { }
}

class b {
function c() {  }
}

}

However, should it be legal to give a class the same name as
a namespace that's in the same scope? Maybe the code above
should simply fail with a message:

'Fatal error: Cannot redeclare class/namespace b'

This way we could use '::'  :D

Mark Spruiell

20 years ago

> BdB>>The above can either mean "call function c in namespace b under
> BdB>>namespace a" or "call static method c of class b under namespace a".
> BdB>>Since this cannot be determined, "::" cannot be used.
>
> This provided we support nested namespaces. Do we need them?

Nested namespaces are important if PHP is to support a natural
mapping from interface definition languages such as CORBA IDL,
which does allow arbitrarily nested namespaces.

- Mark

Jani Taskinen

20 years ago

On Fri, 2 Dec 2005, Stanislav Malyshev wrote:

>
> BdB>>The above can either mean "call function c in namespace b under
> BdB>>namespace a" or "call static method c of class b under namespace a".
> BdB>>Since this cannot be determined, "::" cannot be used.
>
> This provided we support nested namespaces. Do we need them?

No, we don't need no stinking namespaces. We already have prefixes. :)

--Jani

Stanislav Malyshev

20 years ago

JT>>> This provided we support nested namespaces. Do we need them?
JT>>
JT>>    No, we don't need no stinking namespaces. We already have prefixes. :)

Did I write the word "nested" in invisible font? Funny, I didn't know my
mail client supports it.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Jani Taskinen

20 years ago

On Fri, 2 Dec 2005, Stanislav Malyshev wrote:

>
> JT>>> This provided we support nested namespaces. Do we need them?
> JT>>
> JT>>    No, we don't need no stinking namespaces. We already have prefixes. :)
>
> Did I write the word "nested" in invisible font? Funny, I didn't know my
> mail client supports it.

Yes, but you don't have to think about "nested" if you forget namespaces. :)

--Jani