19 years ago by Greg Beaver — view source — reply

unread

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

19 years ago by Jessie Hernandez — view source — reply

unread

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

19 years ago by Matt Friedman — view source — reply

unread

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.

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

--

--
-- Matt Friedman

19 years ago by Jessie Hernandez — view source — reply

unread

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

19 years ago by dz@bitxtender.com — view source — reply

unread

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

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

19 years ago by oliver.graetz@arcor.de — view source — reply

unread

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

19 years ago by Stanislav Malyshev — view source — reply

unread

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

19 years ago by Matthew C. Kavanagh — view source — reply

unread

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.

19 years ago by dz@bitxtender.com — view source — reply

unread

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

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.

19 years ago by Matthew C. Kavanagh — view source — reply

unread

Don't let the identifiers collide, then.

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

19 years ago by dz@bitxtender.com — view source — reply

unread

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

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

Don't let the identifiers collide, then.

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

19 years ago by Stanislav Malyshev — view source — reply

unread

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

19 years ago by Marcus Boerger — view source — reply

unread

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

19 years ago by Marcus Boerger — view source — reply

unread

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.

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

--

--
-- Matt Friedman

--

Best regards,
Marcus

19 years ago by Jessie Hernandez — view source — reply

unread

Marcus Boerger wrote:

Hello Matt,

bla!

LOL!

--
Jessie

19 years ago by Lorenzo Alberton — view source — reply

unread

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

19 years ago by nicobn@gmail.com — view source — reply

unread

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

I now think '' is the best choice.

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 (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).

19 years ago by Jared Williams — view source — reply

unread

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

19 years ago by Jason Garber — view source — reply

unread

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

19 years ago by Roman Ivanov — view source — reply

unread

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:

Use :.
Make : to work like ::.
Make : to work like ->.
But no one will agree to it anyway, so I stop here.

19 years ago by oliver.graetz@arcor.de — view source — reply

unread

Roman Ivanov schrieb:

Radical idea:

Use :.

Make : to work like ::.

Make : to work like ->.

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

19 years ago by Matthew C. Kavanagh — view source — reply

unread

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.

19 years ago by Jasper Bryant-Greene — view source — reply

unread

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

19 years ago by Eric Coleman — view source — reply

unread

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

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

19 years ago by dz@bitxtender.com — view source — reply

unread

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:

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

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

19 years ago by oliver.graetz@arcor.de — view source — reply

unread

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

19 years ago by Hartmut Holzgraefe — view source — reply

unread

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

19 years ago by oliver.graetz@arcor.de — view source — reply

unread

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

19 years ago by Robert Deaton — view source — reply

unread

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

I'd hate to see it be <-, looks too much like ->.
Foo<-bar<-Baz::getTest()->foo();

but I agree that ::: should be ruled out all together, its too similar to ::.

I'd almost rather have %% over <-, and even that looks kinda messy.

I think if I had to, I'd pick :>, although there still isn't any that
stands out to me as "Hey, this is definately a good choice"

--
--Robert Deaton

19 years ago by Alan Knowles — view source — reply

unread

This is getting kind of fun to read since we have unicode, perhaps we
should use one of those characters ;) - I'm sure I can find a chinese
character that means namespace for it ;)

define('foo',1);define('bar',2);var_dump(foo<-bar);

personally I would prefer ":" if it is at all feasible,
(changing the parser to enforce whitespace on a ? b : c with a compile
error would be a perfectly acceptable penalty. - It pales into
insignficance compared to the clone() issue that has to be dealt with in
upgrading PHP4->PHP5 ;)

Regards
Alan

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

I'd hate to see it be <-, looks too much like ->.
Foo<-bar<-Baz::getTest()->foo();

but I agree that ::: should be ruled out all together, its too similar to ::.

I'd almost rather have %% over <-, and even that looks kinda messy.

I think if I had to, I'd pick :>, although there still isn't any that
stands out to me as "Hey, this is definately a good choice"

--
--Robert Deaton

19 years ago by comex — view source — reply

unread

(This is my first post to this list and of course just my opinion.)

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

Yes, it is blocky, as is the :: for class scopes.

But it is the same width as six colons. I agree that : should be
used even if it means requiring whitespace in some obscure case,
mainly because everything else suggested here just doesn't look right.
%%, as mentioned, is blocky, as with many of the other ones. And <-
to me looks backwards and implies that x->y = y<-x. (Same with any of
the operators starting with <, since that seems to be impossible
anyway.)

If : can't be used, however, %% is my favorite.

19 years ago by Eric Coleman — view source — reply

unread

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

-- Eric

Eric Coleman

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

============================3D=====================

19 years ago by Matt Friedman — view source — reply

unread

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

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

-- Eric

Eric Coleman

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 | | | |
===============================================================3D=======

--

--

--
-- Matt Friedman

19 years ago by nicobn@gmail.com — view source — reply

unread

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

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

--

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

19 years ago by Matthew C. Kavanagh — view source — reply

unread

+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? ;)

19 years ago by Matt Friedman — view source — reply

unread

Quite Right, stupid on my part, sorry.

The original post HAS an attachment, but here you go ;-)

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

--
-- Matt Friedman

19 years ago by Sara Golemon — view source — reply

unread

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

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

19 years ago by Jessie Hernandez — view source — reply

unread

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

19 years ago by Jacques Marneweck — view source — reply

unread

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/

19 years ago by Marcus Boerger — view source — reply

unread

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

19 years ago by Sean Coates — view source — reply

unread

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

19 years ago by Stanislav Malyshev — view source — reply

unread

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

19 years ago by Jessie Hernandez — view source — reply

unread

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:

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

19 years ago by Bart de Boer — view source — reply

unread

Bart de Boer wrote:

What was the argument against '::' again?

Jessie Hernandez wrote:

Found it...

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

19 years ago by Lukas Smith — view source — reply

unread

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

19 years ago by oliver.graetz@arcor.de — view source — reply

unread

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

19 years ago by Stanislav Malyshev — view source — reply

unread

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

19 years ago by Bart de Boer — view source — reply

unread

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

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

19 years ago by Mark Spruiell — view source — reply

unread

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

19 years ago by Jani Taskinen — view source — reply

unread

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

19 years ago by Stanislav Malyshev — view source — reply

unread

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

19 years ago by Jani Taskinen — view source — reply

unread

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

19 years ago by oliver.graetz@arcor.de — view source — reply

unread

Jani Taskinen schrieb:

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

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

Nope. If you forget namespaces in that statement, then you have to think
ONLY about "nested", meaning questioning

"This provided we support nested."

which sheds another light on this. Why forget about nesting here and not
everywhere else? No more nested parentheses, no more nested for() loops,
no more nested if(). That's braindead! The concept of being able to nest
stuff is natural to programming.

So, by trying to question namespaces at all, JT still answered the
nesting question ;-)

OLLi

namespace separator ideas

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.

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

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.

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

Regards,

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

Regards,

-- Eric

OK, you requested for it! g
OLLi

Namespace Operators

Namespace Operators

-- Eric

OK, you requested for it! g
OLLi

Namespace Operators

Namespace Operators

Namespace Operators

Namespace Operators

Namespace Operators

sum | | +1 | +1 | +3 | +0 | -2 | +2 | -1 |
-1 | +2 | +1 | +1 | -2 | +1 | | | |

Namespace Operators

sum | | +1 | +1 | +3 | +0 | -2 | +2 | -1 |
-1 | +2 | +1 | +1 | -2 | +1 | | | |

PAAM actually means "once" :)

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

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

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

namespace separator ideas

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.

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

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.

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

Regards,

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

Regards,

-- Eric

OK, you requested for it! g OLLi

Namespace Operators

Namespace Operators

-- Eric

OK, you requested for it! g OLLi

Namespace Operators

Namespace Operators

Namespace Operators

Namespace Operators

Namespace Operators

sum | | +1 | +1 | +3 | +0 | -2 | +2 | -1 | -1 | +2 | +1 | +1 | -2 | +1 | | | |

Namespace Operators

sum | | +1 | +1 | +3 | +0 | -2 | +2 | -1 | -1 | +2 | +1 | +1 | -2 | +1 | | | |

PAAM actually means "once" :)

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

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

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

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.

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

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.

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

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

OK, you requested for it! g
OLLi

OK, you requested for it! g
OLLi

sum | | +1 | +1 | +3 | +0 | -2 | +2 | -1 |
-1 | +2 | +1 | +1 | -2 | +1 | | | |

sum | | +1 | +1 | +3 | +0 | -2 | +2 | -1 |
-1 | +2 | +1 | +1 | -2 | +1 | | | |

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