Whitespace around Paamayim Nekudotayim (double colon)

3 years ago by Matthew Brown — view source

unread

Hey all,

Is there interest in prohibiting whitespace around double colons in the
next major PHP version?

I was surprised to learn that PHP treats :: similar to ->, allowing double
colons like

A::
b();

Looking at the top 2,000 packages in Packagist I can't find any evidence of
people using a double colon with whitespace around, and my suspicion is
that the use of it is basically non-existent.

I wonder if there's a benefit to removing a small potential footgun from
the language? I can't really see any benefit to keeping it (unless it
turns out my analysis is wrong, and it's actually wildly popular).

Best wishes,

Matt

3 years ago by Stephen Reay — view source

unread

Hey all,

Is there interest in prohibiting whitespace around double colons in the
next major PHP version?

I was surprised to learn that PHP treats :: similar to ->, allowing double
colons like

A::
b();

Looking at the top 2,000 packages in Packagist I can't find any evidence of
people using a double colon with whitespace around, and my suspicion is
that the use of it is basically non-existent.

I wonder if there's a benefit to removing a small potential footgun from
the language? I can't really see any benefit to keeping it (unless it
turns out my analysis is wrong, and it's actually wildly popular).

Best wishes,

Matt

Hi Matt,

As a user-land developer, I would be very much against changing this.

I’m sure it’s probably not a particularly common way to format code, but the ability to chain method calls, starting from a static call and have it formatted with one method call per-line is quite useful IMO, eg:

MyModelClass
	::find(1)
	->where(‘foo’, `time()`, ‘>’)
	->where(‘bar’, null, ‘is not’)
	->readAll();

But more generically - I can’t see why you’d think that this one particular instance of extra whitespace being insignificant is a problem, when extra whitespace is not significant anywhere?

In other worse, can you explain why you think it’s a problem that whitespace is not significant in static method calls, but it’s not a problem everywhere else where it’s not significant?

The two following examples are the extremes of extra whitespace vs minimal whitespace, and your suggestion would introduce an arbitrary inconsistency for one specific case.

&lt;?php namespace Foo; class Bar implements \JsonSerializable { public function jsonSerialize(): mixed {return self::class;} public static function create(): static { return new static(); }} $f = Bar::create(); echo \json_encode($f); var_dump($f); ?>

&lt;?php
namespace
   Foo
;

class
Bar
   implements
   \JsonSerializable
{
   public
   function
   jsonSerialize
   (

   )
   :
   mixed
   {
      return
         self
         ::
         class
         ;
   }

   public
   static
   function
   create
   (

   )
   :
   static
   {
      return
         new
         static
         (

         )
         ;
   }
}
$f
   =
   Bar
   ::
   create
   (

   )
;
echo
\json_encode
(
   $f
)
;
var_dump
(
   $f
)
;
   ?>

Cheers

Stephen

3 years ago by Matthew Brown — view source

unread

There are plenty of places where PHP doesn't allow whitespace currently.

The most comparable example is between namespace separators:

Ns \ bar();
Ns \ SOME_CONST;

are both syntax errors.

MyClass::bar() and MyClass::SOME_CONST are often used in place of
Ns\bar() and Ns\SOME_CONST because the former invokes the autoloader in
a way the latter does not. My gut tells me they should behave the same way
with respect to whitespace, too.

In some situations PHP does treat the identifier "Foo::bar" differently
to "Foo :: bar":

class A {
public static function b() {
return 5;
}
}

echo "A::b"(); // works
echo "A :: b"(); // fatal error

3 years ago by Sara Golemon — view source

unread

On Mon, Feb 15, 2021 at 8:53 AM Matthew Brown matthewmatthew@gmail.com
wrote:

There are plenty of places where PHP doesn't allow whitespace currently.

The most comparable example is between namespace separators:

Ns \ bar();
Ns \ SOME_CONST;

That change was made very recently (8.0) and was done for technical reasons
(attributes) not aesthetic ones.

Personally, I agree that adding whitespace around double colon is a suspect
move, but breaking valid code for the sake of one's own sense of aesthetic
doesn't progress the language, it regresses it.

-Sara

TL;DR - I vote No to such a change

3 years ago by Matthew Brown — view source

unread

That change was made very recently (8.0) and was done for technical
reasons (attributes) not aesthetic ones.

Personally, I agree that adding whitespace around double colon is a
suspect move, but breaking valid code for the sake of one's own sense of
aesthetic doesn't progress the language, it regresses it.

-Sara

TL;DR - I vote No to such a change

OK, I take your point.

While I'm at it, I would also be happy for PHP to treat this as a parse
error (vs a runtime error, as it does currently):

$a->
list($a, $b) = $c;

But requiring zero whitespace after -> would invalidate quite a bit of
existing code.

My reasons aren't just aesthetic, mind – this also leads to ambiguity
during autocompletion in IDEs. I realise it's not internals' job to make
that easier, though.

3 years ago by Rowan Tommins — view source

unread

The most comparable example is between namespace separators:

Ns \ bar();
Ns \ SOME_CONST;

are both syntax errors.

As Sara says, this only became an error in 8.0, and there was a rather
specific reason for it, but I think there is a philosophical difference,
too.

"" is part of a single piece of syntax: a fully-qualified class,
constant, or function name. You can't write $foo\Bar or Foo$bar or
$foo$bar.

"::" on the other hand is an operator that can be used in a variety of
ways. You can write $foo::bar(), Foo::$bar, $foo::$bar, {$foo .
'Handler'}::handle(), parent::foo(), and so on. It stands to reason that
it would have the same whitespace rules as any other operator.

I was surprised to learn that PHP treats :: similar to ->

I think it would be rather surprising if it didn't treat the two
operators similarly, since they're so closely related.

I wonder if there's a benefit to removing a small potential footgun from
the language?

I'm not really sure what the footgun here is. Adding newlines around
just about any operator you can think of will lead to code that confuses
at first glance:

$x = [
    1,
    2,
    3,
    4,
    5
]

// Wait, we're not done yet...

[2];

Short of changing the entire language from semicolon-delimited to
newline-delimited, that's inevitable.

Regards,

--
Rowan Tommins
[IMSoP]

3 years ago by Matthew Brown — view source

unread

Thanks, now I realise I was probably wrong to bring this up.

I had it in my mind that "::" could never appear chained together (thinking
of constants), but it's just that I've never seen code that chains them
together – i.e. this is valid:

A::b()::c()::$d::$e = 5;

The most comparable example is between namespace separators:

Ns \ bar();
Ns \ SOME_CONST;

are both syntax errors.

As Sara says, this only became an error in 8.0, and there was a rather
specific reason for it, but I think there is a philosophical difference,
too.

"" is part of a single piece of syntax: a fully-qualified class,
constant, or function name. You can't write $foo\Bar or Foo$bar or
$foo$bar.

"::" on the other hand is an operator that can be used in a variety of
ways. You can write $foo::bar(), Foo::$bar, $foo::$bar, {$foo .
'Handler'}::handle(), parent::foo(), and so on. It stands to reason that
it would have the same whitespace rules as any other operator.

I was surprised to learn that PHP treats :: similar to ->

I think it would be rather surprising if it didn't treat the two
operators similarly, since they're so closely related.

I wonder if there's a benefit to removing a small potential footgun from
the language?

I'm not really sure what the footgun here is. Adding newlines around
just about any operator you can think of will lead to code that confuses
at first glance:

$x = [
1,
2,
3,
4,
5
]

// Wait, we're not done yet...

[2];

Short of changing the entire language from semicolon-delimited to
newline-delimited, that's inevitable.

Regards,

--
Rowan Tommins
[IMSoP]

--

To unsubscribe, visit: https://www.php.net/unsub.php

3 years ago by Larry Garfield — view source

unread

Thanks, now I realise I was probably wrong to bring this up.

I had it in my mind that "::" could never appear chained together (thinking
of constants), but it's just that I've never seen code that chains them
together – i.e. this is valid:

A::b()::c()::$d::$e = 5;

You were not wrong to bring it up. It's a valid question if you're confused; the end, correct result is to just say "yep, that's a thing" and move on, but that doesn't mean asking about it was wrong. :-)

--Larry Garfield

3 years ago by Andreas Heigl — view source

unread

Hey Matt.

Am 15.02.21 um 06:14 schrieb Matthew Brown:

Hey all,

Is there interest in prohibiting whitespace around double colons in the
next major PHP version?

I was surprised to learn that PHP treats :: similar to ->, allowing double
colons like

A::
b();

Looking at the top 2,000 packages in Packagist I can't find any evidence of
people using a double colon with whitespace around, and my suspicion is
that the use of it is basically non-existent.

I wonder if there's a benefit to removing a small potential footgun from
the language? I can't really see any benefit to keeping it (unless it
turns out my analysis is wrong, and it's actually wildly popular).

Additional whitespace means any whitespace. Not just line ends. And
I've seen far too many codebases that use spaces around double colons
(or arrows or a lot of other things) like this:

A :: b();

Not allowing that on a language level just to avoid people shooting
their own foot while we have enough userland tools to at least make
people aware of such issues (like php_codesniffer, php-cs-fix or –
perhaps even better – phpunit) feels a bit drastic to me.

Cheers

Andreas

                                                          ,,,
                                                         (o o)

+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+