adopt PSR-0, PSR-1, and PSR-2?

[D. Dante Lorenso]

Has Joomla declared its intention of adopting PSR-0, PSR-1, and/or PSR-2?

http://www.php-fig.org

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md

I would like to see that happen.

-- Dante

[Niels Braczek]

Am 19.08.2012 22:49, schrieb D. Dante Lorenso:

> Has Joomla declared its intention of adopting PSR-0, PSR-1, and/or PSR-2? [...]

> I would like to see that happen.

/me too.

Regards
Niels

--
| http://barcamp-wk.de · 2. Barcamp Westküste Frühjahr 2013 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Rouven Weßling]

I knew this would come eventually ;)

While this is on jgen I'm speaking with the platform maintainer hat on since we've discussed this among the maintainers. Also Andrew is currently a member of the FIG for the joomla project.

On 19.08.2012, at 22:49, "D. Dante Lorenso" <da...@lorenso.com> wrote:

> Has Joomla declared its intention of adopting PSR-0, PSR-1, and/or PSR-2?
>
> http://www.php-fig.org
>
> https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

As Andrew recently pointed out that's gonna be tough. I can see us adding a PSR-0 mode to JLoader for convenience but our naming scheme doesn't completely match PSR-0. At least for the non-namespaced variant we certainly won't adopt it. We'll reconsider this when we namespace the platform.

> https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md

We follow this pretty closely in the platform, some older classes define some constants when loaded which is probably a grey area but the things in PSR-1 are mostly best practices already followed. (Except PSR-1 links back to PSR-0 which we obviously don't follow).

> https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md

Here's were things fall apart. To me personally there's no interoperability gain to have by adopting this and at least Andrew agrees and voted -1 on this.

We just went trough the entire code base working towards one common - and tightly enforced - codestyle. There's no gain to be had by replacing it with a new one. The changes would touch every single line simply due to the difference in indentation character (space vs. tab). As we refine our code style in the future I'm sure we'll take a close look as PSR-2 and take elements from it but I'm reasonable sure to say we'll never follow it completely.

Best regards
Rouven

[Sam Moffatt]

My favourite feature of PSR-0 is that using the suggested autoloader
implementation you get a fatal error for calling class_exists if it
doesn't find the file it wants to autoload. Pretty cool to program
defensively and have your entire app stop working! The entire approach
of PSR-0 in my mind reflects a level of arrogance that this is the
only one ignoring the fact that functions like 'class_exists' exist
and that throwing a fatal error for a class_exists is backwards.
Further the view is that you will only ever have one autoloader or
else to me just doesn't feel right particularly when PHP went from
having a single autoloader implementation limitation to providing
multiple and the simple fact that the way we structure the CMS is
facilitated through multiple autoloaders that means we'd be building
our own implementation of PSR-0 in which case we're not following the
'standard' but building our own. And realistically we've already got
our own class naming and loading standard so change for the sake of
backwards incompatible change doesn't make sense.

Cheers,

Sam Moffatt
http://pasamio.id.au

[Mike Smith]

Like ;)

> --
> You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
> To post to this group, send an email to joomla-de...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
>