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.
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.
--To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/edb4a48f-f752-4bdb-825c-fe3965ac1615%40googlegroups.com.
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.
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.
On Oct 23, 2013, at 5:07 PM, Amy Stephen <amyst...@gmail.com> wrote: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.
> I could definitely live with this. It reminds me more of Paul's draft when we called PSR-X.
<https://github.com/pmjones/fig-standards/blob/master/proposed/psr-4-autoloader/psr-4-autoloader-mini.md>
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.
--
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.
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 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.
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.
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.
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.
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/2a96db1d-17b5-4e1f-a6e3-3315d496341e%40googlegroups.com.
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.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 view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/0D3A588C-4567-4DF7-9B9B-FE07E9DA7EE8%40gmail.com.
> On Oct 24, 2013, at 2:28 PM, Amy Stephen <amyst...@gmail.com> wrote: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. ;-)
>
>> 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>
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.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.When those approaches are ready, we can put them in front of people for a vote.
- 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.
What is the problem? Is it really that hard to work together?
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
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. :)
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 specI 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 featureSeems 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 notConfusion is bad.Which of these shitty options would people prefer?
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.
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/880A4825-A051-457D-8FB1-C25057895A65%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANAnSg2LdFpSaKQbpDAQ5stScJVyZHtJhWFQq0g6CvXjCTv_tQ%40mail.gmail.com.
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
We're producing specifications, not iPad's.
We have to go with one.