[PSR-12] Anonymous classes

[Korvin Szanto]

Hey FIG,

I believe that anonymous classes should be as similar to closure declaration as possible leaving the bracket on the same line as the class keyword unless the implements wrap:

$instance = new class extends FooClass implements FooInterface {

    use FooTrait;

};

$instance = new class extends FooClass implements 

    FooInterface,

    BarInterface,

    BazInterface

{

    use FooTrait;

    use BarTrait;
    use BazTrait;

};

Does anyone have any objections to this?

[Michael Cullum]

As a note, Korvin and I have already discussed this and agree its the best way to follow the precedent set by the guidelines for anonymous functions in PSR-2.

--
Thanks,
Michael Cullum
PSR-2 Editor

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANeXGWXnj3mYqa1viN%3D36bkXogaHLtYjmy%3DzBkqU%2B_%2BUYcFF4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Alexander Makarov]

Agree.

[Korvin Szanto]

I'd also like to require the "Class" keyword be capitalized to make it clear that the class is anonymous and not a definition. So I've opened a pull request that requires the implementer defer to PSR-2 section 4 for anonymous classes except for the bracket placement and the capitalized "Class" keyword [1].

Let me know what you think

[1] https://github.com/KorvinSzanto/fig-standards/blob/master/proposed/extended-coding-style-guide.md

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/68f72520-272e-416b-bc1a-828539aa2ccc%40googlegroups.com.

[Josh Di Fabio]

> I'd also like to require the "Class" keyword be capitalized to make it clear that the class is anonymous and not a definition.

Interesting. To me, it would be quite strange to enforce
capitalisation of a language keyword given that, by standard, no one
does capitalises keywords in PHP. Is there a single other keyword we
capitalise by standard?

If anything, the capitalised Class keyword would look much more like a
class name than it would a keyword, making it easier to mistake the
following for instantiation of a named class when quickly grokking
code:

$foo = new Class ...

Whereas, to me, the following clearly looks different to instantiation
of a named class when grokking:

$foo = new class ...

> https://groups.google.com/d/msgid/php-fig/CANeXGWWzibeteEGNfEtArLc_-HDqAMcoP9yjdYm7CsrcwoTAoA%40mail.gmail.com.

[Korvin Szanto]

On Fri, Sep 18, 2015 at 1:23 AM Josh Di Fabio <joshd...@gmail.com> wrote:

> I'd also like to require the "Class" keyword be capitalized to make it clear that the class is anonymous and not a definition.

Interesting. To me, it would be quite strange to enforce
capitalisation of a language keyword given that, by standard, no one
does capitalises keywords in PHP. Is there a single other keyword we
capitalise by standard?

If anything, the capitalised Class keyword would look much more like a
class name than it would a keyword, making it easier to mistake the
following for instantiation of a named class when quickly grokking
code:

$foo = new Class ...

Whereas, to me, the following clearly looks different to instantiation
of a named class when grokking:

$foo = new class ...

To me, the capitalized "Class" following the new keyword tells me that the class is being instantiated and isn't something else. My code has ONLY classnames capitalized, so it very clearly jumps out at me. Take the following for example:

<?php

$closure = function($foo, $bar) {

    return function($foo, $bar) {
         doSomething();

    };

};

$class = new class($foo, $bar) {
    function __construct($foo, $bar) {

        doSomething();

    }

};

$instance = new Class($foo, $bar) {
    function __construct($foo, $bar) {

        doSomething();

    }

};

Obviously this isn't likely to show up in code, but I'm sure in 10 years I'll be debugging this or similar. The first two things at a glance look exactly the same to me while the third is clearly an anonymous class. 

I think of it as the "Class" keyword being a stand in for the classname, + some extra syntax sugar.

I should also say that this was met with general approval in the IRC.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAKiSzdDRx3fB694nYziKsy2L%2Bwd4_N4%3DVKrsQt8QfD_eRLve%3Dw%40mail.gmail.com.

[Josh Di Fabio]

Fair enough!

Do you think it's significant that we don't capitalise any other
keywords in PHP? Or am I missing some?

> https://groups.google.com/d/msgid/php-fig/CANeXGWWrTa7f_mXE3%3D4Xu4eyhax8sqfURXVD5rPi3noq_rQqtA%40mail.gmail.com.

[Moshe Brevda]

Just jumping in here to support lowercase keywords, as "more psr2-ish"

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAKiSzdCgHc8CnpyyprCvYC%2BGXU%3Dmj0ykeL4gjqYfRwsJ_99k4g%40mail.gmail.com.

[Alessandro Pellizzari]

On 2015-09-18 09:37, Korvin Szanto wrote:

> To me, the capitalized "Class" following the new keyword tells me
> that

> the class is being instantiated and isnt something else. My code has

> ONLY classnames capitalized, so it very clearly jumps out at me. Take
> the following for example:
>
> <?php
>
> $closure = function($foo, $bar) {
>     return function($foo, $bar) {
>          doSomething();
>     };
> };
>
> $class = new class($foo, $bar) {
>     function __construct($foo, $bar) {
>         doSomething();
>     }
> };
>
> $instance = new Class($foo, $bar) {
>     function __construct($foo, $bar) {
>         doSomething();
>     }
> };

I disagree, and I quoted the example in purpose. Following this
reasoning, function should be capitalized too, in the first part:

$closure = Function($foo, $bar) {
return Function($foo, $bar)...

The third example makes me think "Class" is a proper class, not an
anonymous one, while the second ("class") directly tells me it's a
keyword, and thus an anonymous class.

Bye.

[Matteo Beccati]

On 18/09/2015 10:23, Josh Di Fabio wrote:
> If anything, the capitalised Class keyword would look much more like a
> class name than it would a keyword, making it easier to mistake the
> following for instantiation of a named class when quickly grokking
> code:
>
> $foo = new Class ...
>
> Whereas, to me, the following clearly looks different to instantiation
> of a named class when grokking:
>
> $foo = new class ...

I agree.


Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

[Larry Garfield]

I agree. new Something is how I recognize a real class. If anything, lowercase makes it more obvious that it's a language construct, not a real class name.

--Larry Garfield

[Korvin Szanto]

Fair enough, I've removed that requirement from the open pull request.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/0fb6b6aa-76c0-4848-a027-de54882dc1b2%40email.android.com.

[Phil Sturgeon]

Hey, I like that you're taking on an extended style guide, one certainly needs to be made.

1. Don't call it PSR-12 yet, that is not accurate. A PSR does not have a number until it passes an Entrance vote. 

2. There are a lot of other style considerations that need to be worked into the next style guide PSR.

3. I would recommend making a replacement for PSR-2, not an extension. Take PSR-2, and just add new stuff to it. Don't undo anything, or make breaking changes, but add stuff to it. 

I talked a bit about that idea here:

https://philsturgeon.uk/php/2014/02/13/phpfig-autoloaders-amendments-and-the-15th-standard/

Let me know if you want any advice or anything but that article covers a lot of it. Deprecation and replacement is how most standards bodies (or recommendations bodies whatever) work, so I'd like us to keep that going now that we have the bylaws for it.

[Michael Cullum]

Hi Phil,

It passed entrance vote a while back, so we are fully entitled to call it PSR-12?

Please see https://github.com/php-fig/fig-standards/pull/611, https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/php-fig/P9atZLOcUBM/_jwkvlYKEAAJ and https://github.com/php-fig/fig-standards/tree/master/proposed

--

Michael C

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/f4accd51-d9c0-46c8-b7f5-5bbbc9dc8961%40googlegroups.com.

[Phil Sturgeon]

Whoooo, just the website needs an update then.

That pesky submodule. :)

[Korvin Szanto]

@phil lol.

I'll check out your blog post some time in the next few days. Michael and I are usually in the IRC if you're interested in discussing it.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/3be9e3f7-43dd-4c67-8692-d44e3e34f654%40googlegroups.com.

[Phil Sturgeon]

Had a bit of a chat yesterday.

6:05:54 PM MichaelC: You seemed to kind of disagree with the PSR extension model by the sounds of your ML post

6:06:17 PM philsturgeon: 2.) Why Bother

6:06:22 PM philsturgeon: 1st paragraph: bang on

6:06:27 PM philsturgeon: 2nd paragraph: meh who cares

6:07:00 PM philsturgeon: FIG isn't on a mission to get all/loadsof existing projects using it, but to offer a good standard for new projects, new versions, etc.

6:07:13 PM philsturgeon: making a softer, nicer, weaker standard that will have less friction shouldnt be a goal

6:07:29 PM philsturgeon: PSR-2 was written when PHP 5.2 was the hotness, so lets make a new one because shit is missing. 

6:08:08 PM philsturgeon: especially RE https://github.com/php-fig/fig-standards/wiki/Further-Style-Guide-Considerations there are vague things, unintentional enforced rules which were just down to bad wording, etc. 

6:08:19 PM MichaelC: A few people, lead by pmj, weren't initally a fan of PSR-12 as they felt that it would be prescriptive instead of descriptive and that's why it's written very much in a way that it will only include 'new functionality and clarification'

6:08:24 PM MichaelC: but I want to include operators

6:09:16 PM philsturgeon: anonymous classes and things like that aren't drastically new or different from anything else. PSR-2 can be applied to them easily enough.

6:09:23 PM philsturgeon: as for the rest https://github.com/php-fig/fig-standards/wiki/Further-Style-Guide-Considerations that stuff is old enough 

6:10:13 PM philsturgeon: even if PHP 7 features are ignored now, there's plenty of PHP 5.4-5.5 stuff to add into a PSR-2 replacement, and be descriptive instead of prescriptive 

6:10:54 PM philsturgeon: but please please please don't extend PSR-2. "To be PSR-12 compliant I must read and understand PSR-2 and PSR-1 and PSR-0 or maybe PSR-4?" ugh

6:10:57 PM MichaelC: Yeah

clemf [~tex...@50.252.15.145] entered the room. (6:11:30 PM)

6:11:35 PM MichaelC: What's wrong with extending? It makes it a lot clearer to extend what the differences are

6:11:45 PM MichaelC: Whereas a replacement means duplicating everything

6:12:53 PM MichaelC: It makes it a lot clearer what the differences are if you extend*

6:15:28 PM MichaelC: https://gist.github.com/michaelcullum/c025f3870c9ea1dd2668 btw

clemf_ [~tex...@50.252.15.145] entered the room. (6:15:49 PM)

clemf left the room (quit: Ping timeout: 240 seconds). (6:16:26 PM)

6:16:52 PM philsturgeon: MichaelC: deprecation and replacement was discussed as a better option and put into bylaws with exactly this sort of situation in mind: https://github.com/php-fig/fig-standards/blob/master/bylaws/006-psr-amendments.md

6:17:57 PM MichaelC: hmm

6:18:06 PM philsturgeon: "clear what the differences are" is not particularly relevant. we don't need to tell the user a winding interesting historical story of progressive enhancements of style over the years, just tell them where to put their damn brackets 

6:18:31 PM philsturgeon: > Hey, PSR-2 is a bit old, go see PSR-12 for new stuff.

6:18:42 PM philsturgeon: "Oh this looks pretty familiar. Oooh they got anon classes in there too"

6:18:43 PM philsturgeon: or

6:18:54 PM philsturgeon: "dunno what PSR-2 is but it sounds old so I'll go learn this other thing" 

Basically, do to PSR-2 with PSR-12 what PSR-4 did to PSR-0. We don't need a million little partial standards that reference around all over the Internet, just replace them as we go according the bylaws that we agreed upon. :)