Re: [PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)
On Mon, Feb 15, 2021, at 2:25 PM, Matthew Brown wrote: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)
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;
On Mon, 15 Feb 2021 at 15:06, Rowan Tommins wrote:
> On 15/02/2021 14:52, Matthew Brown wrote:
> > 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]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)
On 15/02/2021 14:52, Matthew Brown wrote:
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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)
On Mon, 15 Feb 2021 at 11:05, Sara Golemon wrote: > 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.
Re: [PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)
On Mon, Feb 15, 2021 at 8:53 AM Matthew Brown 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
Re: [PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)
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
Re: [PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)
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:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)
> On 15 Feb 2021, at 12:14, Matthew Brown wrote: > > 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. ``` ``` ``` ``` Cheers Stephen
[PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)
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
