Re: Questioning the validity of PSR-1 and PSR-2

[Jason Judge]

On Friday, 4 January 2013 09:37:43 UTC, George Zankevich wrote:

...
Moving on to PSR-2, the stated goal is to "reduce cognitive friction when scanning code from different authors." I emphatically disagree with the sentiment that a PSR is necessary for this. Every IDE has the ability to reformat code and there are numerous non-IDE tools to do this.

Yes, and that is the problem I guess we are trying to avoid - code being reformatted each time a new developer touches it.
 

There is an obvious benefit in having library/framework authors write code in the style that they are comfortable with, which is that they can ignore trivial issues like where they put their braces and focus on solving problems.

They are still free to do this. Nobody has to follow PSR-2. A project may declare it to be their standard style, but that is a concern for the project to enforce if they wish.
 

Some examples of code formatting tools - http://stackoverflow.com/questions/149600/php-code-formatter-beautifier-and-php-beautification-in-general

Certainly a useful list.

Drupal refuse to confirm - fine - I'm personally leaving Drupal behind me, as it is in a world of its own, doing its own things in its own special way. I just could not be bothered with that.

That is my understanding as a casual observer at least. Others will have more to add about the suggestion of refactoring, I'm sure.

-- Jason

[Larry Garfield]

On 1/4/13 7:12 AM, Jason Judge wrote:

> Drupal refuse to confirm - fine - I'm personally leaving Drupal behind
> me, as it is in a world of its own, doing its own things in its own
> special way. I just could not be bothered with that.
>
> That is my understanding as a casual observer at least. Others will have
> more to add about the suggestion of refactoring, I'm sure.

Side note: That is becoming less and less the case every day. You
should keep an eye on Drupal 8 development. We're a Symfony app now,
and while there's still a lot of legacy design and code Drupal 8 is
moving MUCH farther into the modern era.

If you don't want to use Drupal, meh, to each his own, but the "because
it's so different" argument is growing smaller all the time.

--Larry Garfield, Drupal

[Phil Sturgeon]

"The latter three points are issues of style and have no bearing on interoperability. I do not believe that they belong in this PSR."

This depends heavily on your definition of interoperability.

While PSR-0 looks at basic "make sure it aint broke" interoperability, PSR-1 takes a slightly higher road and helps make sure that from the outside looking in, it all looks the same. Is this style guide? No. It means that a consistent interface can be kept for any components being used.

Why does this matter?

Let's use PyroCMS - my project - as an example.

I'd like PyroCMS to use consistent camelCase or snake_case, StudlyCaps, DoUchEFormat, whatever, so I don't have half-and-half throughout my codebase. Having a mix-match of every casing style ever for each component in use would make my project look like a joke. I'd hate this, my developer users would hate this, and it would mean I am highly unlikely to use whatever components did not match that initial style.

By everyone shirking their own preferences we have one consistent style from the outside looking in, meaning I can use ANY package, not just whichever happens to be camelCase.

Now. PSR-2 takes this a little further and says "Everyone on the inside should be the same too". This is nice for some, but not for others. For those that don't care they don't need to worry about PSR-2. As I see it, if you're going to go half way and make it look nice on the outside then you might as well go the whole hog and make things consistent internally too.

That last one is up to you, but it means the use-case above (which is a fairly fundamental example of why this group exists) is taken care of nicely.

[Jason Judge]

On Friday, 4 January 2013 17:56:23 UTC, Larry Garfield wrote:

On 1/4/13 7:12 AM, Jason Judge wrote:

...

If you don't want to use Drupal, meh, to each his own, but the "because
it's so different" argument is growing smaller all the time.

That's good to hear. The "because it's so different" argument really revolved around the amount of personal investment needed to understand enough of Drupal to get even the tiniest thing done. And up to now, that investment of time has not been something that could be carried forward into other projects.

The use of tried-tested-and-trusted packages is a great move, and can only make the framework/CMS easier to maintain and support, and easier for developers to make the right decisions when they are constructing an application.

That kind of touches on what Phill was saying: making the framelook "look good" from the inside as well as the outside. That is about providing a familiar environment that a developer or supporter (and I have been left to support a number of Drupal 7 projects) are instantly at home in. That can only lead to fewer mistakes and much more obvious fixes to issues that don't break other things unexpectedly.

Anyway - I don't want to take this thread way off-topic, and the intention wasn't to "dis" the hard work that Drupal developers have put in over the years. I realise legacy is a really hard beast to fight. However, with the FIG interoperability recommendations, it is also becoming easier for developers to jump to new frameworks without a massive learning curve, and without as much porting work as there used to be. I think that means projects need to be less afraid of losing chunks of their support base when changing things, as projects and developers become a lot more mobile.

-- Jason

[Jason Judge]

(This was a reply to Larry - not sure if I pressed the right "reply" button ;-)

[Phil Sturgeon]

Hey Jason. Hope all is well back in Newcastle :)

Please can we avoid talking too much about peoples opinions on Drupal, this is a different conversation. 

[Larry Garfield]

On 01/06/2013 06:24 AM, Jason Judge wrote:
>
> However, with the FIG interoperability recommendations, it is also
> becoming easier for developers to jump to new frameworks without a
> massive learning curve, and without as much porting work as there used
> to be. I think that means projects need to be less afraid of losing
> chunks of their support base when changing things, as projects and
> developers become a lot more mobile.
>
> -- Jason

Amen and pass the sweet potatoes to that. :-)

--Larry Garfield of GoPHP5 infamy

[Jordi Boggiano]

> By muddying the water and having fig address both interface and
> implementation, it loses some of it's authority since it addresses both
> style and structure. This makes it look less serious from the outside.
> In other words, PSR should define mandatory standards while something
> separate should define optional ones. Separation of concerns.

There is (un?)fortunately no such thing as mandatory standards. I think
it's fine to have recommendations for coding style even if they are not
followed by all, it at least gives a direction to people that would come
looking for one, so that maybe N years down the line most of the
ecosystem actually follows it.

Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

[Moisa Teodor]

Hi all,

Regarding implementations, some standard bodies provide reference implementations for the specs they produce, to name a few: 

 - JCP (Java) provides RI's for most of the JSRs (ex: Jersey, the RI for JAX-RS - JSR-311)

 - W3C provides libwww - the RI for HTTP communication (among others)

 - Apache Shindig - the RI for OpenSocial

etc.

I think that a reference implementation is a good thing. It can serve as example and/or, if needed, as the basis for a more complex implementation of the standard. As long as the implementor has the choice of using or not using a RI, I think it's alright to have them. 

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

For more options, visit https://groups.google.com/groups/opt_out.

--
Doru Moisa
web: http;//moisadoru.wordpress.com
tel: +40 720 861 922
Bucharest, Romania

[Phil Sturgeon]

> If we take the lessons we've learned from object model design, we know that what's on the inside is irrelevant to architecture. The point of having standardised interfaces is that we don't need to care about the inside at all. 

Ok well if we're going to ignore my examples of making consistent implementations and focus only on the points of interface building, let's go with that. 

The "inside" of an interface needs a style, so before we start building out a whole bunch of interfaces it seems fairly important for us all to be on the same page about camelCase or snake_case for those methods, or the implementations down the line will all be inconsistent and lead to the issues I have pointed out. 

> The job of standards bodies is to define interfaces. They solve the problem of architecture, not implementation. 

The PHP-FIG is not a standards body, it's a group that makes recommendations for ways in which frameworks (and other projects in general) can combine their efforts to create interoperable code. That gives it a fairly open-ended remit when it comes to what it releases as PSR's.

> My contention is that while, yes, it's useful to have a guideline for coding style, a PSR is not the best place to formalise it.

Where would be better? Another group? 

> By muddying the water and having fig address both interface and implementation, it loses some of it's authority since it addresses both style and structure. 

How can you build a solid consistent structure without addressing style? 

[Andreas Möller]

> If we take the lessons we've learned from object model design, we know that what's on the inside is irrelevant to architecture. The point of having standardised interfaces is that we don't need to care about the inside at all.

Have you ever bought a really cheap computer and opened it up? You would know then why it's so cheap - because some people don't care about the inside of it.

It pays to buy quality products.

If you are a craftsman, you create quality products - and get paid for it.

People will laugh about comments like "The point of having standardised interfaces is that we don't need to care about the inside at all." in years down the road. Believe me, you will, too. If you don't, why are you even on this list?


Best regards,

Andreas