[PSR-4] Only document changes from PSR-0 (experimental approach)

[Beau Simensen]

Hi all,

As Phil has mentioned many times in recent days, alternative approaches to PSR-4 are not looked upon kindly. There was one exception mentioned, that being one basically built off of PSR-0. I've been thinking about it for the last day and decided to try and see how it would look. My results can be found in this gist:

https://gist.github.com/simensen/d303dbb6e3f83fefb073

I think for this approach to work it would pretty much need to be JUST THIS. We'd have to not try to add a lot more to it. We are just documenting the key differences:

• No special handling of "_" in class names
  
• That there is this notion of a namespace prefix
  
• That the namespace prefix would result in removing the namespace prefix from the fully-qualified class name during the transformation
  

I added the last line about the "don't throw exceptions" since 1) people seem to think that is important to add and 2) people seem to think that PSR-0 actually requires you to throw exceptions... otherwise I would have left it off entirely. :) Happy to remove it as I thought it was tighter w/o out. :)

What this buys us that we can better leverage the foundation in place with PSR-0. We can avoid having to find ways to discuss the complicated relationship between namespace prefix and the path (that seems to be a big sticking point right now) by not even introducing the concept... PSR-0 never talked about how to put things in directories like '.', './src', './lib', or whatever; and implementations handled this fine. We can also get away without having to talk about any handling of multiple mappings of the same prefix to multiple paths... Composer and several other PSR-0 implementations do that already; it is an implementation detail we don't need to specify it.

I think we will also be able to get away without any example implementations. We can put anything we want to in the meta document for that. The examples (namespace prefix, fqcn, resulting file) show what is going on well enough that a someone should be able to write some code to make those transformations happen without us holding their hands.

In reality, this is an attempt to get closer to the roots for PSR-4 but it is also an alternative to the heavy version that we have now. The heavier it is, the more complicated things become and the more bikeshedding that happens on edge cases and wording.

We all know what we want. I feel that something like this would say pretty clearly what that is: PSR-0 without special handling for _ and for allowing the removal of a certain number of namespace directories.

This is not a vote. This is an experiment to see if it could be done, what it would look like, and to gauge interest in whether or not this would be something the group is interested in pursuing as an alternative to the path we've gone down to this point.

Thoughts?

[Andreas Hennings (donquixote)]

The main problem is that the "relationship" or "mapping" aspect is much more important for PSR-4 than for PSR-0.

If you know a solution for this, go ahead.

Unlike some others in this group, i like experiments :)

[Beau Simensen]

On Tuesday, October 22, 2013 3:37:47 PM UTC-5, Andreas Hennings (donquixote) wrote:

The main problem is that the "relationship" or "mapping" aspect is much more important for PSR-4 than for PSR-0.

It is, for sure, and on my first pass at this last week I gave up on it. :) I tried to take a nap today and couldn't because I was thinking about how maybe this wasn't a problem... :)

 

If you know a solution for this, go ahead.

My solution was to ignore it. :) Much like PSR-0 ignored it. Most PSR-0 class loaders actually DO maintain a relationship and mapping between a namespace prefix and a path and they do so without being required to by PSR-0. I thought to myself, huh, maybe we can get away with that with PSR-4 as well? And I got to thinking more...

Basically, rather that focusing on any sort of path mapping, we just focus on the fact that the transformation is that same as it is for PSR-0 with the exception that the namespace prefix isn't included in the final class name transformation. They will have to map to a directory somehow, even if it is just "./" but that was true for PSR-0 but it wasn't mentioned in the spec.

I suspect people will not agree with me, but I will continue to point to PSR-0. The directory in which the files were ultimately located after they were transformed was never discussed. I think we can build on that pretty easily for PSR-4.

This is of course the extreme opposite of the idea of solely focussing on the relationship between namespaces and directories. I liked the other method better, but I think this solution may be more easy to digest for people than what we've been working on as of late. 

[Andreas Hennings]

2013/10/22 Beau Simensen <sime...@gmail.com>

On Tuesday, October 22, 2013 3:37:47 PM UTC-5, Andreas Hennings (donquixote) wrote:

The main problem is that the "relationship" or "mapping" aspect is much more important for PSR-4 than for PSR-0.

It is, for sure, and on my first pass at this last week I gave up on it. :) I tried to take a nap today and couldn't because I was thinking about how maybe this wasn't a problem... :)

 

If you know a solution for this, go ahead.

My solution was to ignore it. :) Much like PSR-0 ignored it. Most PSR-0 class loaders actually DO maintain a relationship and mapping between a namespace prefix and a path and they do so without being required to by PSR-0. I thought to myself, huh, maybe we can get away with that with PSR-4 as well? And I got to thinking more...

Basically, rather that focusing on any sort of path mapping, we just focus on the fact that the transformation is that same as it is for PSR-0 with the exception that the namespace prefix isn't included in the final class name transformation. They will have to map to a directory somehow, even if it is just "./" but that was true for PSR-0 but it wasn't mentioned in the spec.

The mapping in PSR-0 is an invention by Composer, or by people who read stuff into the spec that isn't there.

Even having more than one base directory is an afterthought in PSR-0.

Going this road for PSR-4 results in a very weak spec, where the only constraint left is that the filename (without ".php") equals the (unqualified) class name. You can't say ANYTHING about the directory if you don't talk about a mapping/relationship.

[Phil Sturgeon]

Let's get back to Self Throttling on these PSR-4 items. The two of you know how you both feel on this subject and you both know how I feel. Let's see what the others say.

My opinion - for the others - is that this is the only legitimate path to making an alternative, as it is not based on nothing. It is based on PSR-0, which has certainly not completely failed us so far. 

PSR-0 was not perfect, but if the central goals of PSR-4 are to add two changes (rip out _ and allow namespaces prefixes to map to a base directory) there is a possibility that it can be done in this form. It is an experiment at this point, nothing more. The official proposal is still in review and is still being slightly tweaked.

This should not be considered "a base for a new proposal" either. The entire point of this experiment is to see if PSR-0 can have some minor rule tweaks and be done. If people start recoding it and rewording it and starting over to make a new document then obviously the experiment failed.

People who are not Beau, Amy or Andreas, please throw in your thoughts (one at a time, or get Beau on email).

[Drak]

I  like it.  PSR0 was essentially  a great success. The two main differences  we need now  is to make the file path shorter and remove the meaning of the _. The approach is simple: it takes what works, and amends just what needs to be amended to get what we want.

I imagine we could  see us coming to agreement,  and have a shiny new PSR4 - yay :)

In terms of reviewing his text, I personally am  happy with it as is.  It achieves exactly  what we have been debating. It concise and understandable and relies on a rock solid base of PSR0. Building on top of what has been proven to work is a good strategy.

Regards,

Drak

--
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/edb4a48f-f752-4bdb-825c-fe3965ac1615%40googlegroups.com.

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

[Axel Guckelsberger]

I like the pragmatic and simple approach. Nice work!

[Luis Cordova]

yeah this approach from beau is like PSR-0 with this support added for package autoloading, i kind of like it better, simpler, come on guyz!

[Jordi Boggiano]

+1 on this one. Sounds sane and short, the examples are clear. And
FWIW I don't think it's needed to mention directory mapping stuff, the
key of the spec is indeed how to transform a class name (or in this
case part of a class name) into a file name, so it can be found on the
file system.

Cheers

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

[Amy Stephen]

I could definitely live with this. It reminds me more of Paul's draft when we called PSR-X. Short and sweet, no process or mapping details.

[Phil Sturgeon]

On Wednesday, 23 October 2013 18:07:52 UTC-4, Amy Stephen wrote:

I could definitely live with this. It reminds me more of Paul's draft when we called PSR-X. Short and sweet, no process or mapping details.

It always had mapping details. 

[Paul M. Jones]

On Oct 23, 2013, at 5:07 PM, Amy Stephen <amyst...@gmail.com> wrote:

> I could definitely live with this. It reminds me more of Paul's draft when we called PSR-X.

This type of variation has a special place in my heart. Here is one that I think is both closer to PSR-0, PSR-X, and the version that was about to pass before Phil pulled the vote; thanks Beau for the inspiration on this one.

<https://github.com/pmjones/fig-standards/blob/master/proposed/psr-4-autoloader/psr-4-autoloader-mini.md>


--
Paul M. Jones
pmjo...@gmail.com
http://paul-m-jones.com

[Phil Sturgeon]

I disagree that this is closer to what PSR-4 was during its vote. That is either wishful thinking, inaccurate memory or a misunderstanding of peoples current complaints with PSR-4 (historical, and current).

This is the version that was voted on:

https://github.com/philsturgeon/fig-standards/blob/250ea4b8bb780b48b1d0b58bddca63393f23c4e5/proposed/psr-4-autoloader/psr-4-autoloader.md

Differences between your mini approach and the voted one:

• The introduction is generic and explains we're setting out rules for autoloading in general, while the previous version talked a lot about SPL Autoloaders and code stuff, which aims it at autoloader devs only.
• Your mini version does not have a massive definitions section like the voted version (yay)
• The mini version removes the idea of Translations (later referred to as Technique), which people hated (in the voted version and all revisions until I reworded them from Technique to Requirements)
• The voted upon version did not cover case sensitivity at all, and neither does this one really - even though it now does mention case.
• The voted upon version DID cover "base directory" and "mapped files", which was only eluded to vaguely but it probably needs to be pointed out somehow that will happen and the autoloader is in charge.

With all of those differences, saying this mini version is close to the version that was going to pass is highly inaccurate.

I do feel like this mini version is a strong approach and is obviously closer to being what PSR-4 intends to be (PSR-0 + 2 differences) but it misses a very useful point: Vendor Name and Project Name. They should definitely be mentioned in there, as it helps folks realize what is happening.

Unsolved PSR-0 issues

It also does not really solve any of these concerns there were valid about PSR-0: http://blog.ircmaxell.com/2011/11/on-psr-0-being-included-in-phps-core.html

Case folding - which Larry has covered in a recent PR for PSR-4

https://github.com/php-fig/fig-standards/pull/216

This is once again us walking that thin line between "Giving autoloader developers how to build a nice autoloader" and "Pointing out a few edge cases where if they DONT do something, they totally f**k with the chances of autoloaders being interoperable". Just like "Do not throw exceptions" is important, as if you code against A (expecting no exceptions) and B throws exceptions, or worse just throws fatals, you're gonna have a bad time.

Scope - We have a very nice overview and preamble in PSR-4, with contributions from Mike, Paul x2 and myself which I feel hits the nail on the head pretty damn well.

It'll be even better when my PR to remove "resources" is merged (a few conflicts left to solve)

Merge or Switch

So, this is very different to Ye-Olde PSR-X, missing some ideas from PSR-4, not solving some of the issues in PSR-0 but maintaining the simplicity of that "standard".

The question is, do we try and get Pauls Mini version up to snuff, or do we try to trim the fat from PSR-4 as it is?

Either way, I assume this needs to go back to draft.

[Drak]

On 24 October 2013 14:32, Paul M. Jones <pmjo...@gmail.com> wrote:

On Oct 23, 2013, at 5:07 PM, Amy Stephen <amyst...@gmail.com> wrote:

> I could definitely live with this. It reminds me more of Paul's draft when we called PSR-X.

This type of variation has a special place in my heart.  Here is one that I think is both closer to PSR-0, PSR-X, and the version that was about to pass before Phil pulled the vote; thanks Beau for the inspiration on this one.

<https://github.com/pmjones/fig-standards/blob/master/proposed/psr-4-autoloader/psr-4-autoloader-mini.md>

I like the shorter versions a lot:

I do prefer the approach of Beau a little more because it extends PSR0 so it has the sense of building upon PSR0's strength (which are already proven) and extend it with the two changes necessary. Everyone clearly understands PSR0 we know this as a fact already, so something extending PSR4 cannot be misunderstood. 

Simplicity is my preference and it's a lot easier to vote yes to the short versions, than a long proposal with lots of detail. 

Larry mentioned there might have been a criticism of PSR0 not to mention file-path case-sensitivity so it would make sense to address that - but I believe the examples in both Gists are clear enough but it certainly doesnt hurt to mention.

As a way of moving forward, why not put all three to the vote? The winner could go for final voting. 

(Or even put all three to the vote, if one gets an overall majority as if it were the only proposal, then it will pass entirely and become PSR4).

The mood of a lot of people I have heard is they just want to get a working PSR out, they are burned out. Clearly PSR0 with a couple amendments is workable.

I did suggest something similar previously suggesting let's take PSR0, alter the text with our two/three amendments and we should be good to go because we'd be working with something we all trust already. Beau took an alternative way of "extending" the document with the amendments. PMJ has taken the spirit of it as a new document. Clearly there is mileage in this shorter way because essentially all 3 ways are similar. 

I would like thank everyone for their flexibility for considering these alternative ways.

Drak

[Paul M. Jones]

(I have updated the mini-version as a result of Phil's email; see here:

<https://github.com/pmjones/fig-standards/blob/master/proposed/psr-4-autoloader/psr-4-autoloader-mini.md>

-- pmj)

On Oct 24, 2013, at 9:04 AM, Phil Sturgeon <em...@philsturgeon.co.uk> wrote:

> I disagree that this is closer to what PSR-4 was during its vote.

I get that. In return, I assert that it is primarily a reduction, with an eye toward PSR-0 as inspired by Beau, incorporating critical edits since the vote. The way I see it, only three major things are modified from the voted-on proposal.

- The number of special terms is reduced, and they are defined inline as needed.

- Almost the entire original ruleset is still present, though redistributed; the "normalization" rules have been removed, along with references to "one or more base directories" (as PSR-0 did not mention such).

- Incidents of "imperative" language are replaced with "declarative" language, per the wishes of several outspoken critics, but the rules remain identical, and the implementation examples remain unchanged.

> With all of those differences, saying this mini version is close to the version that was going to pass is highly inaccurate.

Not "close to" but "clos*er* to" the voted-on version than the current version in the official repo under "proposed". ;-)

> I do feel like this mini version is a strong approach and is obviously closer to being what PSR-4 intends to be (PSR-0 + 2 differences) but it misses a very useful point: Vendor Name and Project Name. They should definitely be mentioned in there, as it helps folks realize what is happening.

PSR-0 didn't mention "project name" -- as a formal term, that concept only recently made it into the current official "proposed" version (with the mvriel changes). However, I have added "vendor name" to the "top-level namespace" bullet point. I am sympathetic to adding "project/package name" if we feel it's necessary.

> It also does not really solve any of these concerns there were valid about PSR-0: http://blog.ircmaxell.com/2011/11/on-psr-0-being-included-in-phps-core.html
>
> Case folding - which Larry has covered in a recent PR for PSR-4
> https://github.com/php-fig/fig-standards/pull/216

I believe these are solved in the newest revision, 2.2(v) and 2.3(iv). If you see specific discrepancies noted by @ircmaxell and/or Larry not addressed by the mini-version, let me know.

> Scope - We have a very nice overview and preamble in PSR-4, with contributions from Mike, Paul x2 and myself which I feel hits the nail on the head pretty damn well.

Compare this in the current "official" proposed version ...

"""This PSR describes a technique to [autoload][] classes from specified resource paths. It is fully interoperable, and can be used in addition to any other autoloading technique, including [PSR-0][]. This PSR also describes how to name and structure classes to be autoloaded using the described technique.

...

For a _conforming autoloader_ to be able to transform an _autoloadable class name_ into a _resource path_, this specification describes a technique that MUST be applied or taken into account. When the technique is applied, the _conforming autoloader_ can autoload an _autoloadable class name_ from an existing _resource path_.

Aside from technical considerations, this specification also imposes requirements on developers who want their classes to be autoloadable by a _conforming autoloader_. Developers who wish to comply with this specification MUST structure their classes using these same principles."""

... with this in the mini version:

"""This PSR describes a specification for [autoloading][] classes from file paths. It is fully interoperable, and can be used in addition to any other autoloading specification, including [PSR-0][]. This PSR also describes where to place files that will be autoloaded according the specification."""

Seeing as the mini-one does specifies "correspondences" and not "a technique" I think it's all there. (Perhaps "This PSR specifies the correspondence between fully qualified class names and file paths" would be more suitable.)

> Either way, I assume this needs to go back to draft.

I would not assume so, although that is your prerogative as a sponsor. I see this as a revision of the voted-on version, and as I noted, I don't see it as being far enough away from the voted-on to be considered a "from scratch" version any more than the current "official" proposed version is.

[Donald Gilbert]

Paul, point 2.2.iv says "in in".

Other than that it looks good and is very clear. I like both of the new "mini" proposals much better, simply because they are much more clear and to the point.

[Paul M. Jones]

On Oct 24, 2013, at 10:57 AM, Donald Gilbert <dilber...@gmail.com> wrote:

> Paul, point 2.2.iv says "in in".

Fixed; thanks.

[justin]

On Thu, Oct 24, 2013 at 11:36 AM, Paul M. Jones <pmjo...@gmail.com> wrote:

(I have updated the mini-version as a result of Phil's email; see here:

  <https://github.com/pmjones/fig-standards/blob/master/proposed/psr-4-autoloader/psr-4-autoloader-mini.md>

-- pmj)

Any particular reason you're using "MAY" instead of "SHOULD NOT return a value"?

--j

--
http://justinhileman.com

[Paul M. Jones]

My bad. Fixed.

[Beau Simensen]

On Thursday, October 24, 2013 9:04:51 AM UTC-5, Phil Sturgeon wrote:

The question is, do we try and get Pauls Mini version up to snuff, or do we try to trim the fat from PSR-4 as it is?

Either way, I assume this needs to go back to draft.

I've been trying to stay pretty casual with this as an experiment but I'd like to move this to a full blown PR if we're actively considering moving forward with either of this as potential draft candidates. I've received a decent amount of feedback but haven't tried to incorporate any of it as I thought we were just going to see what people thought about the approach in general before we made any decisions.

I think what Paul wrote could work but I also think that what I had written has some merit as well. I'd hate to dismiss my approach prematurely since it seems clear that there is some interest in that approach and even inspired Paul to start from scratch with PSR-4.

I know that some people are concerned with the idea of having PSR-4 built directly on top of PSR-0. That might be something we'd have to vote on to see how the majority feels about it. That seems to be the biggest difference with what I wrote and what Paul wrote.

[Drak]

Beau, 

Could you please merge in all the suggestions you received. It would be nice to see the alternatives side by side.

Drak

--

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/f0562966-1e88-4611-a541-b31e9b6f84a2%40googlegroups.com.

[Paul M. Jones]

On Oct 24, 2013, at 1:44 PM, Beau Simensen <sime...@gmail.com> wrote:

> haven't tried to incorporate any of it as I thought we were just going to see what people thought about the approach in general before we made any decisions.

I like the less-is-more approach better than the more-is-more attitude the current proposal has succumbed to.

> I think what Paul wrote could work but I also think that what I had written has some merit as well. I'd hate to dismiss my approach prematurely since it seems clear that there is some interest in that approach and even inspired Paul to start from scratch with PSR-4.

To be clear, the new revision is not so much "start from scratch" as "a new revision of the voted-on proposal." It is in large part equivalent to the voted-on proposal, with the additions I noted earlier.

> I know that some people are concerned with the idea of having PSR-4 built directly on top of PSR-0. That might be something we'd have to vote on to see how the majority feels about it. That seems to be the biggest difference with what I wrote and what Paul wrote.

/me nods

That is currently the specific issue I have with what Beau has put together. To wit, it is presented as an "extension" of PSR-0. It is my opinion that PSRs in general are not classes to be overridden, but instead should stand pretty much on their own. PSR-1 *refers* to PSR-0, and PSR-2 to PSR-1, but there's no point at which the later ones "override" the earlier ones.

[Phil Sturgeon]

On Thursday, 24 October 2013 11:25:54 UTC-4, Drak wrote:

The mood of a lot of people I have heard is they just want to get a working PSR out, they are burned out. Clearly PSR0 with a couple amendments is workable.

I dont know who you are referring to, but nobody is rushing anything and I won't let some rushed piece of junk through. Let's not make any weird assertions.

People involved are dedicated and working hard, despite this being at least the 4th major revision. 

[Drak]

On 24 October 2013 20:00, Paul M. Jones <pmjo...@gmail.com> wrote:

> I know that some people are concerned with the idea of having PSR-4 built directly on top of PSR-0. That might be something we'd have to vote on to see how the majority feels about it. That seems to be the biggest difference with what I wrote and what Paul wrote.

/me nods

That is currently the specific issue I have with what Beau has put together.  To wit, it is presented as an "extension" of PSR-0.  It is my opinion that PSRs in general are not classes to be overridden, but instead should stand pretty much on their own.  PSR-1 *refers* to PSR-0, and PSR-2 to PSR-1, but there's no point at which the later ones "override" the earlier ones.

But if that is your view, the other approach is to take PSR0's text verbatim, and edit the text so it includes the necessary changes. This is because PSR0 is already tried and tested. it works, people understand it, so it if a perfect template on which to make edits. This was you dont have to "extend" the document. PSR0 is already agreeable, so making the few small edits to address our new requirements means it's almost perfect from the very get go.

Drak

[Phil Sturgeon]

On Thursday, 24 October 2013 15:00:34 UTC-4, pmjones wrote:

That is currently the specific issue I have with what Beau has put together.  To wit, it is presented as an "extension" of PSR-0.  It is my opinion that PSRs in general are not classes to be overridden, but instead should stand pretty much on their own.  PSR-1 *refers* to PSR-0, and PSR-2 to PSR-1, but there's no point at which the later ones "override" the earlier ones.

+1 to this. His "extension" wording was definitely not a route we should go down. PSR's need to be standalone wherever possible - and there is no reason here why PSR-4 needs to rely on (and override bits of) PSR-0. 

[Paul M. Jones]

On Oct 24, 2013, at 2:07 PM, Drak <dr...@zikula.org> wrote:

> take PSR0's text verbatim, and edit the text so it includes the necessary changes.

I agree, and that's part of what I did. One can look at the mini-version as a merge between exactly that attempt, and the voted-on proposal.

[Amy Stephen]

Beau - would you mind creating PR's on Paul's? He has adapted _considerably_ given what he has directly attributed as inspiration by your effort. Between Phil's video, your work, Drak getting on board, and then Paul adapting to your direction, has the potential of turning the tide on this but it's important to get it back into the editor's hands, too. My fear is if we are not careful we are going to get back into a "less collaborative" stance.

So it's clear, I also have a "version" of the existing PSR-4 out there but I'm watching to see where this is going and happy to abandon that work if it appears minds are clicking together, again.

It really looks like many people are doing what they can to adapt, I'm encouraged again this might just work.

[Paul M. Jones]

On Oct 24, 2013, at 2:28 PM, Amy Stephen <amyst...@gmail.com> wrote:

> It really looks like many people are doing what they can to adapt, I'm encouraged again this might just work.

/me wipes brow

Lots of minor edits and additions. Please review newest revision here:

[Paul M. Jones]

On Oct 24, 2013, at 3:25 PM, Paul M. Jones <pmjo...@gmail.com> wrote:

>
> On Oct 24, 2013, at 2:28 PM, Amy Stephen <amyst...@gmail.com> wrote:
>
>> It really looks like many people are doing what they can to adapt, I'm encouraged again this might just work.
>
> /me wipes brow
>
> Lots of minor edits and additions. Please review newest revision here:
>
> <https://github.com/pmjones/fig-standards/blob/master/proposed/psr-4-autoloader/psr-4-autoloader-mini.md>

No other comments at this point? This is the quietest the list has been on this topic in a long time. Normally there's a flurry of followup. Either nobody cares, or there's nothing left to say; neither of those sounds right to me. ;-)

[Amy Stephen]

Might be worth doing a poll to gauge membership's preference? We've seen so much back and forth about verbose vs terse. Maybe ask what people prefer between the existing PSR-4, full bodied flavor, and a light version, given what you have now. That should help provide direction so this thing can get wrapped up.

[Beau Simensen]

On Friday, October 25, 2013 9:49:45 AM UTC-5, Amy Stephen wrote:

Might be worth doing a poll to gauge membership's preference? We've seen so much back and forth about verbose vs terse. Maybe ask what people prefer between the existing PSR-4, full bodied flavor, and a light version, given what you have now. That should help provide direction so this thing can get wrapped up.

I'd also like to see a poll to find out how people feel about building directly on top of PSR-0 like I did with my experimental proposal.

I don't think my experimental proposal is all that crazy and I don't think it's clear that we absolutely must not go down that road. That said, I think Paul's mini version could be a fine way to go, too, so whatever happens it is a win. I would just rather not dismiss my experimental proposal without more feedback and a general idea how the group as a whole feels about building PSR-4 on top of PSR-0.

[Amy Stephen]

First things first, then. Beau - can you get PR's to Paul's so that we have one abbreviated version? Personally, I see these as very similar. If we can get it down to two, then a survey makes more sense.

[Andreas Hennings]

2013/10/25 Amy Stephen <amyst...@gmail.com>

First things first, then. Beau - can you get PR's to Paul's so that we have one abbreviated version? Personally, I see these as very similar. If we can get it down to two, then a survey makes more sense.

There is a voting method which is very useful to find a "best of many" for more than two candidates.

http://en.wikipedia.org/wiki/Majority_judgment

Basically it lets you "rate" every option and then takes the median.

With a regular voting system, if you have e.g. two left-wing candidates and one right-wing, then the right-wing might win only because the left-wing votes are split on two candidates. This does not happen with the above mentioned voting method.

 

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/8ibeZRXsclM/unsubscribe.
To unsubscribe from this group and all its topics, 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/2a96db1d-17b5-4e1f-a6e3-3315d496341e%40googlegroups.com.

[Amy Stephen]

On Friday, October 25, 2013 10:52:44 AM UTC-5, Andreas Hennings (donquixote) wrote:

2013/10/25 Amy Stephen <amyst...@gmail.com>

First things first, then. Beau - can you get PR's to Paul's so that we have one abbreviated version? Personally, I see these as very similar. If we can get it down to two, then a survey makes more sense.

There is a voting method which is very useful to find a "best of many" for more than two candidates.

http://en.wikipedia.org/wiki/Majority_judgment

Basically it lets you "rate" every option and then takes the median.

With a regular voting system, if you have e.g. two left-wing candidates and one right-wing, then the right-wing might win only because the left-wing votes are split on two candidates. This does not happen with the above mentioned voting method.

The egos in this group are getting in the way of progress.  And, sadly, this has been going on for a long time now.

We are not voting for people.

We agree on the essence of "what is PSR-4" -- the essence of "what is PSR-4" has not changed one iota since it's introduction.

We have two approaches -- a verbose approach that is getting more verbose as more people work with it. And, we have a brief approach.

• We have a process defined by FIG for FIG.
• We have two editors.
• PR's can be made to either copy in the hands of the editors.

When those approaches are ready, we can put them in front of people for a vote.

What is the problem? Is it really that hard to work together?

[Andreas Hennings]

After following this thread for a while (from a place where it was difficult to respond), here are some thoughts, summarized.

Mainly, what are the main differences from the main proposal, and in how far is this good or bad.

1. Focus / Where do we "start"?

Do we focus more on the autoloader or more on the library/code? And if we start with the autoloader, then how easy is it to draw conclusions about file and directory structure?

We had, more or less, these options being suggested:

a) The class loader must follow these steps, and if it finds a matching file, it must include that. (older main proposal)

b) The files must be layed out such that the following class loader would work. (recent main proposal)

c) The files must be layed out such that the FQCN "matches" with the file path. (Bernhard, myself)

e) When loading a file for a FQCN, then the FQCN and the file path must "match". (PSR-0, and this recent one by Paul we are discussing in this thread)

This latter one (e) is actually ok. It starts with autoloading behavior, but makes it trivial to conclude instructions for file layout. And it does not impose implementation details or a specific algorithm. It also does not say "MUST include that file", because this could be problematic (e.g. in case of multiple matches). Instead it says if a file is included, then it must be one that matches.

2. How do we introduce the "relationship" or "mapping" ?

Or do we introduce it at all?

We had some proposals where we explicitly say that a relationship has to be defined, specified, etc.

But we also had some "must correspond with" where the introduction of the relationship was not as explicit.

This most recent one by Paul has a "corresponds to" without really explaining what it means. I used to have a problem with that, but maybe it is ok.

3. How do we explain what a "match" is?

a) Active steps: namespace separators MUST be replaced with ...

b) String equality: The remaining part of the file path MUST be equal to the relative class name, after replacing ... and appending ".php".

c) Talking about subfolders: "The contiguous sub-namespace names after the "qualified name" correspond to subdirectories of matching case within a "base directory", in which the namespace separators represent directory separators." (recent proposal by Paul discussed in this thread)

I personally think the string equality approach (b) is more clear and preferable.

Also if we talk about string equality, it is pretty clear that it has to be the same case. Otherwise they are not equal.

The subfolder approach is a little ambiguous, because it does not really mean a trail of nested subfolders, but could also be understood as a bunch of "parallel" subfolders.

4. How much "definitions" fine-print do we need?

No strong opinion here. :)

2013/10/24 Paul M. Jones <pmjo...@gmail.com>

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/8ibeZRXsclM/unsubscribe.
To unsubscribe from this group and all its topics, 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/0D3A588C-4567-4DF7-9B9B-FE07E9DA7EE8%40gmail.com.

[Drak]

On 25 October 2013 14:55, Paul M. Jones <pmjo...@gmail.com> wrote:

> On Oct 24, 2013, at 2:28 PM, Amy Stephen <amyst...@gmail.com> wrote:
>
>> It really looks like many people are doing what they can to adapt, I'm encouraged again this might just work.
>
> /me wipes brow
>
> Lots of minor edits and additions.  Please review newest revision here:
>
> <https://github.com/pmjones/fig-standards/blob/master/proposed/psr-4-autoloader/psr-4-autoloader-mini.md>

No other comments at this point? This is the quietest the list has been on this topic in a long time. Normally there's a flurry of followup. Either nobody cares, or there's nothing left to say; neither of those sounds right to me. ;-)

I think we're all exhausted ;) 

But as far as your text goes, I have nothing more to add.

Drak

[Phil Sturgeon]

On Friday, 25 October 2013 12:42:29 UTC-4, Amy Stephen wrote:

On Friday, October 25, 2013 10:52:44 AM UTC-5, Andreas Hennings (donquixote) wrote:

2013/10/25 Amy Stephen <amyst...@gmail.com>

First things first, then. Beau - can you get PR's to Paul's so that we have one abbreviated version? Personally, I see these as very similar. If we can get it down to two, then a survey makes more sense. 

There is a voting method which is very useful to find a "best of many" for more than two candidates.

http://en.wikipedia.org/wiki/Majority_judgment

Basically it lets you "rate" every option and then takes the median.

With a regular voting system, if you have e.g. two left-wing candidates and one right-wing, then the right-wing might win only because the left-wing votes are split on two candidates. This does not happen with the above mentioned voting method.

The egos in this group are getting in the way of progress.  And, sadly, this has been going on for a long time now.

We are not voting for people. 

We agree on the essence of "what is PSR-4" -- the essence of "what is PSR-4" has not changed one iota since it's introduction.

We have two approaches -- a verbose approach that is getting more verbose as more people work with it. And, we have a brief approach. 

• We have a process defined by FIG for FIG.
• We have two editors.
• PR's can be made to either copy in the hands of the editors.

When those approaches are ready, we can put them in front of people for a vote.

What is the problem? Is it really that hard to work together?

I don't know what you're talking about Amy.

Everyone has been working together (even folks who disagree with each other) and egos have never been an issue in the end. We are working together, and being rude to people while we're trying to get things done is unhelpful at best.

So, we have Beau's "extension of PSR-0" version.

We have Paul's mini version which has pros and cons, but is nice and short and similar to PSR-0.

We have the current version in proposed which is incredibly verbose and unlike PSR-0, but tries to cover everyones concerns.

That makes for 3 options. I'm not sure why people are arguing over vote strategy, but I would very much just like to ask people A, B or C and see which approach gets the most support. This also not going to be a formal vote, but a simple poll to ask which direction people want to head. If they keep with the current document we keep it in Review. If it's one of the other two we roll back to Draft and get going again with that version. This does not need to be complicated.

I'd personally like to see Beau's version change to be entirely standalone, as the way the Scope and Overview are worded is dangerous and scary.

On Friday, 25 October 2013 14:40:59 UTC-4, Drak wrote:

On 25 October 2013 14:55, Paul M. Jones <pmjo...@gmail.com> wrote:

> On Oct 24, 2013, at 2:28 PM, Amy Stephen <amyst...@gmail.com> wrote:
>
>> It really looks like many people are doing what they can to adapt, I'm encouraged again this might just work.
>
> /me wipes brow
>
> Lots of minor edits and additions.  Please review newest revision here:
>
> <https://github.com/pmjones/fig-standards/blob/master/proposed/psr-4-autoloader/psr-4-autoloader-mini.md>

No other comments at this point? This is the quietest the list has been on this topic in a long time. Normally there's a flurry of followup. Either nobody cares, or there's nothing left to say; neither of those sounds right to me. ;-)

I think we're all exhausted ;) 

But as far as your text goes, I have nothing more to add.

Drak

Speak for yourself, I can do this shit for days.

On Friday, 25 October 2013 13:36:56 UTC-4, Andreas Hennings (donquixote) wrote:

After following this thread for a while (from a place where it was difficult to respond), here are some thoughts, summarized.

Mainly, what are the main differences from the main proposal, and in how far is this good or bad.

1. Focus / Where do we "start"?

Do we focus more on the autoloader or more on the library/code? And if we start with the autoloader, then how easy is it to draw conclusions about file and directory structure?

We had, more or less, these options being suggested:

a) The class loader must follow these steps, and if it finds a matching file, it must include that. (older main proposal)

b) The files must be layed out such that the following class loader would work. (recent main proposal)

c) The files must be layed out such that the FQCN "matches" with the file path. (Bernhard, myself)

e) When loading a file for a FQCN, then the FQCN and the file path must "match". (PSR-0, and this recent one by Paul we are discussing in this thread)

This latter one (e) is actually ok. It starts with autoloading behavior, but makes it trivial to conclude instructions for file layout. And it does not impose implementation details or a specific algorithm. It also does not say "MUST include that file", because this could be problematic (e.g. in case of multiple matches). Instead it says if a file is included, then it must be one that matches.

True, but this document does not say wether or not multiple base directories (the only way to get multiple matches) are allowed or not - unlike the main proposal. This was an issue in PSR-0 as well, and people complained that an autoloader which supported multiple directories for a mapping were not compliant with PSR-0. 

This means we need to explicitly say:

A) Features may be available in the autoloader that are not in the spec

I don't like this, because it should be fairly obvious already, but also suggests that you can do what you like - which isn't what a spec is about.

B) Explicitly allow this feature

Seems a bit weird to name one feature out of potentially unlimited potential features, but does at least cover this one instance.

C) Do nothing and leave people to be confused about if they can do it or not

 

Confusion is bad.

Which of these shitty options would people prefer?

2. How do we introduce the "relationship" or "mapping" ?

Or do we introduce it at all?

We had some proposals where we explicitly say that a relationship has to be defined, specified, etc.

But we also had some "must correspond with" where the introduction of the relationship was not as explicit.

This most recent one by Paul has a "corresponds to" without really explaining what it means. I used to have a problem with that, but maybe it is ok.

3. How do we explain what a "match" is?

a) Active steps: namespace separators MUST be replaced with ...

b) String equality: The remaining part of the file path MUST be equal to the relative class name, after replacing ... and appending ".php".

c) Talking about subfolders: "The contiguous sub-namespace names after the "qualified name" correspond to subdirectories of matching case within a "base directory", in which the namespace separators represent directory separators." (recent proposal by Paul discussed in this thread)

I personally think the string equality approach (b) is more clear and preferable.

The descriptions you provided for Active Steps and String Equality are the same thing (but the first has a funny name). We NEVER actually suggested that the items in the doc were sequential pseudo-code, people just thought that for a while. We have always used "string equality" which people still take as "so I literally have to use str_replace to change \ to / (or whatever)" which is completely inaccurate. 

 

(c) is relatively clear, but I don't like using the word contiguous. If we're targeting the PHP community it might be an idea not to use too many fancy words. I guarantee somebody will send us a pull request thinking its a typo within the first week.

Also if we talk about string equality, it is pretty clear that it has to be the same case. Otherwise they are not equal.

You'd think so huh. Again, case needs to be specifically covered.

 

The subfolder approach is a little ambiguous, because it does not really mean a trail of nested subfolders, but could also be understood as a bunch of "parallel" subfolders.

Wording issue.

 

4. How much "definitions" fine-print do we need?

No strong opinion here. :)

PSR-0 didn't have em, so not sure if PSR-4 needs to have em. I'm not against the current PSR-4 document (I like it) but less things might be better. Who knows.

[Andreas Hennings]

2013/10/25 Phil Sturgeon <em...@philsturgeon.co.uk>

On Friday, 25 October 2013 13:36:56 UTC-4, Andreas Hennings (donquixote) wrote:

After following this thread for a while (from a place where it was difficult to respond), here are some thoughts, summarized.

Mainly, what are the main differences from the main proposal, and in how far is this good or bad.

1. Focus / Where do we "start"?

Do we focus more on the autoloader or more on the library/code? And if we start with the autoloader, then how easy is it to draw conclusions about file and directory structure?

We had, more or less, these options being suggested:

a) The class loader must follow these steps, and if it finds a matching file, it must include that. (older main proposal)

b) The files must be layed out such that the following class loader would work. (recent main proposal)

c) The files must be layed out such that the FQCN "matches" with the file path. (Bernhard, myself)

e) When loading a file for a FQCN, then the FQCN and the file path must "match". (PSR-0, and this recent one by Paul we are discussing in this thread)

This latter one (e) is actually ok. It starts with autoloading behavior, but makes it trivial to conclude instructions for file layout. And it does not impose implementation details or a specific algorithm. It also does not say "MUST include that file", because this could be problematic (e.g. in case of multiple matches). Instead it says if a file is included, then it must be one that matches.

True, but this document does not say wether or not multiple base directories (the only way to get multiple matches) are allowed or not - unlike the main proposal. This was an issue in PSR-0 as well, and people complained that an autoloader which supported multiple directories for a mapping were not compliant with PSR-0. 

This means we need to explicitly say:

A) Features may be available in the autoloader that are not in the spec

I don't like this, because it should be fairly obvious already, but also suggests that you can do what you like - which isn't what a spec is about.

B) Explicitly allow this feature

Seems a bit weird to name one feature out of potentially unlimited potential features, but does at least cover this one instance.

C) Do nothing and leave people to be confused about if they can do it or not

 

Confusion is bad.

Which of these shitty options would people prefer?

We should keep the main text simple, and then add some "fine print" for clarification.

The question is whether the fine print should be part of the "requirements" or if it should be in a "notes" section.

As I see it, a "Notes" section would be stuff that is actually clear from the spec, but people are "too stupid" to understand it. Putting stuff in the spec means that we admit the spec is ambiguous and needs this extra line.

E.g. if there is a law "people and children have the right to xy" and later you come across another law which says "citizens have have the right to yz" then you may remember that children have to be mentioned separately, and if they don't then it does not apply to them.

So instead, the lawmaker uses some formulation that clarifies that children are included, but that "citizens" would have been sufficient. (not sure atm how to do that in English)

(the original historical example was too racist to mention it here)

 

[Paul M. Jones]

On Oct 25, 2013, at 12:36 PM, Andreas Hennings <lemon....@gmail.com> wrote:

> After following this thread for a while (from a place where it was difficult to respond), here are some thoughts, summarized.
> Mainly, what are the main differences from the main proposal, and in how far is this good or bad.

I understand that this took some time and effort to put together, but I am wiped out and unable to dedicate the time and effort it deserves for a response. Just reading it makes me more tired. However, I will do what I can.

> 1. Focus / Where do we "start"?
> Do we focus more on the autoloader or more on the library/code? And if we start with the autoloader, then how easy is it to draw conclusions about file and directory structure?

As has been the case from the very beginning, we concentrate on both. They are co-equally important and rely on each other both directly and indirectly.

> e) When loading a file for a FQCN, then the FQCN and the file path must "match". (PSR-0, and this recent one by Paul we are discussing in this thread)
>
> This latter one (e) is actually ok.

I am glad you think so.

> 2. How do we introduce the "relationship" or "mapping" ?

It's there already, both in the "macro" and "mini" versions.

> 3. How do we explain what a "match" is?
> a) Active steps: namespace separators MUST be replaced with ...
> b) String equality: The remaining part of the file path MUST be equal to the relative class name, after replacing ... and appending ".php".
> c) Talking about subfolders: "The contiguous sub-namespace names after the "qualified name" correspond to subdirectories of matching case within a "base directory", in which the namespace separators represent directory separators." (recent proposal by Paul discussed in this thread)
>
> I personally think the string equality approach (b) is more clear and preferable.
> Also if we talk about string equality, it is pretty clear that it has to be the same case. Otherwise they are not equal.

Except that anything even resembling that might possibly be construed as an implementation detail, algorithm, or otherwise imperative has been railed against at length by a very vocal set of critics. Having that kind of fight *yet again* (or worse, succumbing to "but this time it's OK because I agree with it already") is high on my list of things to avoid..

> 4. How much "definitions" fine-print do we need?
> No strong opinion here. :)

Thank God.

[Amy Stephen]

On Friday, October 25, 2013 2:32:10 PM UTC-5, Phil Sturgeon wrote:

On Friday, 25 October 2013 12:42:29 UTC-4, Amy Stephen wrote:

 

being rude to people while we're trying to get things done is unhelpful at best.

My apologies. :(

[Drak]

Paul,

I honestly think your mini version can pass exactly as is: PSR0 was simple, and everyone understood it as history shows. The mini version is equally simple and understandable. The examples tables acts like a perfect set of tests, and there is supplementary example code. It's crystal clear.

The result of endless discussion will be endless editing. We've got a long version, edited for months. That's more or less ready but the complexity of the document means a lot more can be debated, although the document is a lot better that is was. 

We now have a mini version, which frankly hasn't come out of nowhere, it's the result of a long process and collectively realising we have come back to simplicity. 

So I think voting members probably have enough information to go by. Both options work: but for me, simpler is better and I personally with vote for the simpler version of the PSR.

Regards,

Drak

--

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/880A4825-A051-457D-8FB1-C25057895A65%40gmail.com.

[Hari K T]

Can't we keep both the versions. So for those who love simplicity can read it, and others can check for future reference ?

Hari K T

You can ring me : +91 9388 75 8821

http://harikt.com , https://github.com/auraphp 

Skype  : kthari85

Twitter : harikt

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

[Amy Stephen]

On Friday, October 25, 2013 5:07:09 PM UTC-5, Drak wrote:

Paul,

I honestly think your mini version can pass exactly as is: PSR0 was simple, and everyone understood it as history shows. The mini version is equally simple and understandable. The examples tables acts like a perfect set of tests, and there is supplementary example code. It's crystal clear.

The result of endless discussion will be endless editing. We've got a long version, edited for months. That's more or less ready but the complexity of the document means a lot more can be debated, although the document is a lot better that is was. 

We now have a mini version, which frankly hasn't come out of nowhere, it's the result of a long process and collectively realising we have come back to simplicity. 

So I think voting members probably have enough information to go by. Both options work: but for me, simpler is better and I personally with vote for the simpler version of the PSR.

Regards,

Drak

+1 - Three Cheers Drak!
 

[Phil Sturgeon]

We're producing specifications, not iPad's. We have to go with one. 

[Hari K T]

We're producing specifications, not iPad's.

Oh I don't like  iPad's ;)

 

We have to go with one. 

Hope everything is getting green ;) .