Package-Oriented Autoloader, Round 2

[Paul Jones]

Hi everybody,

After the "proposal changed during voting" fiasco, and given that at least one voting member waited until the voting period to voice modifications, I am re-opening the discussion on the proposal found here:

<https://github.com/php-fig/fig-standards/blob/master/proposed/package-oriented-autoloader.md>

Please make your opinion known here.


-- pmj

[Zachary King]

Hi all,

I am still fairly new to PHP so if this is a silly question please don't bite my head off. :)

Is there a significant performance hit for having multiple autoloaders registered?

I was thinking of having three autoloaders in a application and was wondering if it would cause problems. The first one would be the app autoloader which would load the classes specific to that application, then there would be a core autoloader for the core classes, and finally there would be composer for third party packages.

Does that make sense at all or am I off my rocker?

I am thinking that it would allow the app classes to override the core classes, which would in turn override the third party pack.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Evert Pot]

On May 17, 2013, at 4:31 PM, Zachary King <zchr...@gmail.com> wrote:

> Hi all,
>
> I am still fairly new to PHP so if this is a silly question please don't bite my head off. :)
>
> Is there a significant performance hit for having multiple autoloaders registered?

Is there a performance hit? Yes! Is it significant? Depends on your definition.

Aside from the fact that this is not really the appropriate place to ask a question like this, (try stack overflow) the answer to any questions like this is:

Profile and form your own conclusions.

Evert

[Zachary King]

Ok thanks.

[Paul Court]

** Note ** I am not a voting member, just my 2 bits worth.

1.) I like the idea of removing the legacy elements from PSR-0. But perhaps this should be discussed under some system of maintaining and updating the existing PSR's. (Perhaps a PSR-0.2014?, but should probably be discussed elsewhere)

2.) I don't see the need to add the additional complexity, essentially replacing the legacy stuff you are removing, with something else, just for a shallower dir structure.

Using your example of "\Foo\Bar\Dib\Zim" being located in "/path/to/packages/foo-bar/src", am I correct in interpreting that as:-

Foo = Vendor name

Bar = Package

Dib\Zim = Namespace\Class

?

If so, what happens when I have multiple packages from the same vendor? Surly I end up with:-

/path/to/packages/foo-bar/src

/path/to/packages/foo-baz/src

instead of:-

/path/to/packages/foo/bar/src

/path/to/packages/foo/baz/src

Thus breaking the whole concept of a directory structure altogether!

Personally, I would prefer a few "empty" directory levels, and a much simpler and standardised autoloader spec, than the complexity of mapping prefixes to parts of a namespace.

However...

I really do like the idea of a packaging and loader standard, if it was built around the capability of the phar to reach into .tgz archives and load files. So you could have:-

/path/to/packages/foo-bar.tgz

I think this would also require some collaboration with IDE makers to allow autocomplete, code hinting, etc to also look into them.

[Drak]

On 18 May 2013 09:57, Paul Court <pa...@pmcnetworks.co.uk> wrote:

However...

I really do like the idea of a packaging and loader standard, if it was built around the capability of the phar to reach into .tgz archives and load files. So you could have:-

/path/to/packages/foo-bar.tgz

I think this would also require some collaboration with IDE makers to allow autocomplete, code hinting, etc to also look into them.

If you have /path/to/packages/foo-bar.phar then IDEs already recognise it for autocomplete purposes.

Regards,

Drak

[Jason Judge]

On Saturday, 18 May 2013 09:57:40 UTC+1, Paul Court (aka Gargoyle) wrote:

** Note ** I am not a voting member, just my 2 bits worth.

1.) I like the idea of removing the legacy elements from PSR-0. But perhaps this should be discussed under some system of maintaining and updating the existing PSR's. (Perhaps a PSR-0.2014?, but should probably be discussed elsewhere)

2.) I don't see the need to add the additional complexity, essentially replacing the legacy stuff you are removing, with something else, just for a shallower dir structure.

Using your example of "\Foo\Bar\Dib\Zim" being located in "/path/to/packages/foo-bar/src", am I correct in interpreting that as:-

Foo = Vendor name

Bar = Package

Dib\Zim = Namespace\Class

?

If so, what happens when I have multiple packages from the same vendor? Surly I end up with:-

/path/to/packages/foo-bar/src

/path/to/packages/foo-baz/src

instead of:-

/path/to/packages/foo/bar/src

/path/to/packages/foo/baz/src

Thus breaking the whole concept of a directory structure altogether!

 

What sits below (towards the server root directory - sorry, talking about directory trees never makes it easy to understand what directories are higher and lower) of the "src" directory in your examples, is out-of-scope of this PSR. The PSR simply does not care about those directories. It is only dealing with what comes after the src directory, as that is where the directories that match namespace names are located.

Personally, I would prefer a few "empty" directory levels, and a much simpler and standardised autoloader spec, than the complexity of mapping prefixes to parts of a namespace.

And PSR-0 handles that nicely, as does PSR-4. For PSR-0 you would map Foo\Bar onto the src/ directory. For PSR-4 you would map Foo\Bar onto the src/Foo/Bar/ directory - with Foo/Bar/ being entirely optional to you as a developer - if you leave it there, you have the option of using either a PSR-0 or a PSR-4 autoloader. Take those empty directories out and you can just use a PSR-4 autoloader. This is why PSR-0 is not dead - some people may still choose to use it for their projects. Some bigger frameworks with many core classes under their base namespace, PSR-4 offers big advantages.

However...

I really do like the idea of a packaging and loader standard, if it was built around the capability of the phar to reach into .tgz archives and load files. So you could have:-

/path/to/packages/foo-bar.tgz

I think this would also require some collaboration with IDE makers to allow autocomplete, code hinting, etc to also look into them.

I can't imagine what PHP applications are going to look like in ten years time. Maybe just a handful of zip files?

-- Jason

[Paul Jones]

Hi all,

For what it's worth, I intend to re-submit the package-oriented autoloader proposal this coming Friday. If you have fixes or suggestions, now is the time to bring them up.

I have gone back and looked through the emails that appear to have constructive criticism regarding the proposal. The only item of note that I found was from André Romcke, which I have cobbled together from different messages. (André, please correct me if the removal of context changes your meaning.)


> Imo the spec / interface should define what should happen if you get a namespace match but missing file in that namespace, otherwise we push the ambiguity down on implementers / users. And to me, a base system like a autoloader should never cause slow downs by design, so a match not existing on disk should throw a exception, either custom one or something like Logic-/Runtime-Exception.
>
> ...
>
> Basically just returning false if file is not found in matching namespace, allowing other autoloaders in the chain to try as well, something which is not possible with exceptions.
>
> ...
>
> If needed, fix is simple, as proposed before on this list, add a flag for what to actually do on a false match can include the following options:
>
> - NS_MATCH_NO_FILE_EXCEPTION
> - NS_MATCH_NO_FILE_RETURN
> - NS_MATCH_NO_FILE_IGNORE / CONTINUE

I take this to mean that we should specify what happens if an autoloader implementation fails to find the file for a class. There are two considerations to keep in mind:

1. Most of the time an autoloader should not get in the way of other autoloaders when it can't find a file, e.g. by throwing exceptions.

2. Sometimes an autoloader expects to be the last resort, and the implementor wants it to throw an exception when it can't find a file.

As such, I think it's reasonable to add a line to the spec, but using optional language, to indicate that the normal course is to stay out of the way, but that it is allowed if necessary.

- "Exceptions SHOULD NOT be thrown, and errors SHOULD NOT be raised, in the case of a missing file."

The wording is clumsy and probably not broad enough. Thoughts?


-- pmj

[Amy Stephen]

Seems that there is at least some support for superseding PSR-0. I hope that is considered. In the end, I think that will be least confusing and the easiest moving forward.

[Paul Jones]

On May 20, 2013, at 6:30 PM, Amy Stephen wrote:

> Seems that there is at least some support for superseding PSR-0. I hope that is considered. In the end, I think that will be least confusing and the easiest moving forward.

/me nods

I admit, I am uneasy about replacing and deprecating PSR-0.

Anyone else?


-- pmj

[justin]

I'd vote no, if I could vote.

--justin

[Larry Garfield]

I'm not even sure what deprecating PSR-0 would mean in this context. It
effectively means a de facto "vote of no confidence" in PSR-0, since we
cannot and should not "remove" PSR-0. It will always be there; it's
just a matter of what we talk about at conferences. :-)

As I noted before, PSR-X is a superset of PSR-0 iff none of your classes
contain underscores. Are we willing to as a group say "we're breakin'
ur underscores if you want to stick to 'active' specs"?

Before you knee-jerk respond "well duh, WTF are you doing not using
namespaces yet?" keep in mind there are two very important and
influential projects that still use PHP 5.2 and underscores that would
be incompatible with PSR-X: PHPUnit and Twig. Deprecating PSR-0 while
PSR-X still removes the BC handling would be effectively saying "PHPUnit
and Twig, FIG officially tells you to piss off."

I am not sure we want to say that, particularly to such key projects...

--Larry Garfield

[Andreas Möller]

> I admit, I am uneasy about replacing and deprecating PSR-0.

Yes.

While I see there might be an advantage for some in leaving them out, I don't see any disadvantages in having a few more directory levels.

If you are using a modern IDE, you probably don't care in which directory a class resides, as long as you and an autoloader can find it. Not sure though how this affects trying to find a class in a directory structure from the console when you are first diving into it.


Best regards,

Andreas

[Larry Garfield]

I think you misunderstand me.

I'm in favor of the new autoloader. What I'm not comfortable with is
including text in it that says "this replaces PSR-0, don't listen to
that anymore." So far no one has had a really convincing argument why
having PSR-0 and PSR-4 both "FIG recommended and not deprecated" is such
a bad thing.

--Larry Garfield

[Andreas Möller]

> I think you misunderstand me.

Actually, I replied to Paul's statement.

> I'm in favor of the new autoloader.

While I'm not convinced of the usefulness of the autoloader *yet*, I'm not against it.

> What I'm not comfortable with is including text in it that says "this replaces PSR-0, don't listen to that anymore."

I fully agree with that. That's all I'm saying.

> So far no one has had a really convincing argument why having PSR-0 and PSR-4 both "FIG recommended and not deprecated" is such a bad thing.

Best,

Andreas

[Drak]

I would like to bring up the code examples for discussion. 

I've two proposals for the autoloader PSR and made two separate PSRs for them.

1. Let's remove the second implementation - one is enough 

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

2. PHP already terms "fully qualified" class names. so we do not need to define this term. We should use what PHP has defined already

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

Regards,

Drak

[Paul Jones]

On May 21, 2013, at 11:29 AM, Drak wrote:

> I would like to bring up the code examples for discussion.
>
> I've two proposals for the autoloader PSR and made two separate PSRs for them.
>
> 1. Let's remove the second implementation - one is enough
> https://github.com/php-fig/fig-standards/pull/125

As mentioned elsewhere, I think it's useful to have two examples; one for standalone use, and another general-purpose one. But if enough other people feel the same way, I'm happy to remove one or the other.

> 2. PHP already terms "fully qualified" class names. so we do not need to define this term. We should use what PHP has defined already
> https://github.com/php-fig/fig-standards/pull/126

The change appears to be only that we replace the phrase "absolute class name" with "fully qualified class name" (which we used in an earlier version of the proposal).

I'd argue that using "absolute" and "relative" sets up a better relationship and contrast than "fully qualified" and "relative". If we go with "fully qualified" should we also replace "relative" with something else?


-- pmj

[Drak]

There is an interesting point here that strictly speaking PHP.net refers as following:

Unqualified name:
      This is an identifier without a namespace separator, such as Foo

Qualified name:
      This is an identifier with a namespace separator, such as Foo\Bar

Fully qualified name:
      This is an identifier with a namespace separator that begins with a
      namespace separator, such as \Foo\Bar. The namespace \Foo is also a
      fully qualified name.

 

Although an important point however is that autoloaders receive a Qualified name, they do not ever receive a class name prefixed with a \. So new \Foo\Bar is converted to a Qualified name and PHP will send Foo\Barto the autoloader.

Regards,

Drak

[Paul Jones]

On May 21, 2013, at 11:43 AM, Drak wrote:

>> 2. PHP already terms "fully qualified" class names. so we do not need to define this term. We should use what PHP has defined already
>> https://github.com/php-fig/fig-standards/pull/126
>
> There is an interesting point here that strictly speaking PHP.net refers as following:
>
> Unqualified name:
> This is an identifier without a namespace separator, such as Foo
>
> Qualified name:
> This is an identifier with a namespace separator, such as Foo\Bar
>
> Fully qualified name:
> This is an identifier with a namespace separator that begins with a
> namespace separator, such as \Foo\Bar. The namespace \Foo is also a
> fully qualified name.
>
> Although an important point however is that autoloaders receive a Qualified name, they do not ever receive a class name prefixed with a \. So new \Foo\Bar is converted to a Qualified name and PHP will send Foo\Barto the autoloader.

Nice find! I assume it's from <http://php.net/manual/en/language.namespaces.rules.php>.

What's interesting is that the autoloader gets a qualified name that is all-but-fully-qualified (i.e., the only thing missing is the leading backslash). The dual use of qualified and fully qualified I think is a little confusing.

However, in the interest of using standardized language, I can see a case for using the above terms, and changing the code examples to strip a leading backslash (even though it might not be there) to emphasize the idea that what it's receiving is what we've been calling an absolute class name.

Thoughts?


-- pmj

[Drak]

On 21 May 2013 17:57, Paul Jones <pmjo...@gmail.com> wrote:

Nice find! I assume it's from <http://php.net/manual/en/language.namespaces.rules.php>.

However, in the interest of using standardized language, I can see a case for using the above terms, and changing the code examples to strip a leading backslash (even though it might not be there) to emphasize the idea that what it's receiving is what we've been calling an absolute class name.

I wouldn't like that at all - why add code for a situation that does not exist? It's a matter of API, PHP send the class name as seen from the root namespace.

The less hacky way would be to use the words "fully qualified" and state in the PSR that PHP always passes a fully qualified class name resolved from the root namespace, and therefor PHP removes the leading backslash.

Something like this

   "N.B. Implementors should note that PHP autoloading functions receive a fully qualified class name with the leading backslash stripped, so `\Foo\Bar` is received as `Foo\Bar`".

Regards,

Drak

[Paul Jones]

On May 21, 2013, at 12:14 PM, Drak wrote:

> The less hacky way would be to use the words "fully qualified" and state in the PSR that PHP always passes a fully qualified class name resolved from the root namespace, and therefor PHP removes the leading backslash.
>
> Something like this
>
> "N.B. Implementors should note that PHP autoloading functions receive a fully qualified class name with the leading backslash stripped, so `\Foo\Bar` is received as `Foo\Bar`".

Nice phrasing.

Anyone else have an opinion here?


-- pmj

[Amy Stephen]

Larry -

Setting aside the legacy namespacing issue, for a moment, because I believe it needs to be addressed separately.

The reason to replace PSR-0 is that it is no longer needed.

Switching from PSR-0 to PSR-X means two minor changes to the composer.json file - and that's it. PSR-0 namespaces are compliant with PSR-X.

You made a comment about a "vote of no confidence in PSR-0" and I believe that's the wrong way to look at this. (In fact, Larry, I am surprised to hear you make that comment.)

In the time since PSR-0 has been adopted, Composer has come into the picture, and Packagist, both great things for the PHP community. CMS'es have started to work to look to FIG as an important leadership element in the PHP world and now they are attempting to apply the standards to a broader body of work. This broader community base and these emerging technologies mean adaptations are needed. PSR-X is an appropriate adaptation to the guidelines. It continues to ensure interoperability, which is the primary goal, and it does so in a manner that supports existing PSR-0 implementations while providing a better fit for the changing needs of the community.

That's a good thing. 

What we don't want to do is confuse people. We don't need a lot of questions about which standard is better for their needs. We don't need the continued debate about extra folders for those who failed to read between the lines and pick the right one. We don't want to unnecessarily consume what should be productive programming time in communities (like has happened with Drupal) as they grapple with implementation details around PSR-0.

It's time to move forward. Today, PSR-X is a better fit for the PHP community. It builds on success of PSR-0. Those who have adopted PSR-0 are fully compliant with PSR-4. The adaptations mean PSR-X works for full distributions, not just shared packages. It also offers flexibility developers are hoping for so they have freedom to configure their repository and install paths, as desired, and are still able to comply with the guidelines.

IMO, the legacy elements of PSR-0 should be carried forward if those standards are still needed by membership. It sounds to me that they are. So be it.

[justin]

We should really be using RFC 3092-compliant metasyntactic variables, rather than our own non-standard extensions to the series:

    Foo -> Bar -> Baz -> Qux -> Quux

--justin

[Jordi Boggiano]

On 21.05.2013 18:42, Paul Jones wrote:
>> 1. Let's remove the second implementation - one is enough
>> https://github.com/php-fig/fig-standards/pull/125
>
> As mentioned elsewhere, I think it's useful to have two examples; one
> for standalone use, and another general-purpose one. But if enough
> other people feel the same way, I'm happy to remove one or the
> other.

I'd say one for standalone is enough, because those implementing general
purpose ones should:

A) probably not do it.
B) if really needed, gain a deep understanding of the spec and not
copy paste a dummy implementation.

Cheers

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

[Paul Jones]

On May 21, 2013, at 12:48 PM, Jordi Boggiano wrote:

> I'd say one for standalone is enough, because those implementing general
> purpose ones should:
>
> A) probably not do it.

Really? How come?


-- pmj

[Jordi Boggiano]

Well, call me biased but in this age of composer usage I don't really
see a big point to reinvent such a commodity. The only valid argument
IMO might be specific performance requirements.

Anyway even if you count framework implementors and whatever, it's still
not something that many people really need to do.. and again if they do
I'd rather not have them copy paste it from the spec, because if they
build sometihng general purpose most likely they're going to share it.

[Drak]

On 21 May 2013 19:04, Jordi Boggiano <j.bog...@seld.be> wrote:

Well, call me biased but in this age of composer usage I don't really

see a big point to reinvent such a commodity. The only valid argument
IMO might be specific performance requirements.

Anyway even if you count framework implementors and whatever, it's still
not something that many people really need to do.. and again if they do
I'd rather not have them copy paste it from the spec, because if they
build sometihng general purpose most likely they're going to share it.

This is a very lucid point. @pmj - for 99.999% of people, this PSR just defines how they arrange their classes. It's very less little to do with implementation - as with PSR0 in the end, there will be very few implementations and even then, they've practically become useless since Composer came on the scene.  We just don't need two reference implementations.

Regards,

Drak

[Paul Jones]

On May 21, 2013, at 1:04 PM, Jordi Boggiano wrote:

> On 21.05.2013 19:50, Paul Jones wrote:
>>
>> On May 21, 2013, at 12:48 PM, Jordi Boggiano wrote:
>>
>>> I'd say one for standalone is enough, because those implementing general
>>> purpose ones should:
>>>
>>> A) probably not do it.
>>
>> Really? How come?
>
> Well, call me biased

"You're biased." ;-)

> but in this age of composer usage I don't really
> see a big point to reinvent such a commodity.

You might not see the point, but others (for whatever reason) might be unwilling or unable to use Composer. Having a general-purpose example remains useful to those folks, whoever they might be. Indeed, I'd argue that if there's to be one example only, it should be the general-purpose one.


-- pmj

[Drak]

On 21 May 2013 19:34, Paul Jones <pmjo...@gmail.com> wrote:

You might not see the point, but others (for whatever reason) might be unwilling or unable to use Composer.  Having a general-purpose example remains useful to those folks, whoever they might be.  Indeed, I'd argue that if there's to be one example only, it should be the general-purpose one.

The point of the reference implementation is just to make sure the specification is clear. You do not need two examples for this. The closure does that nicely. If people want to see reference implementations  and the innovation that is likely to come if the PSR passes, will be in Zend, Symfony et al. 

You seem very attached to your code but it's superfluous to the PSR. PSR0 had a very similar closure like implementation example and it was enough for a rash of innovation after the fact. 

Drak

[Paul Jones]

On May 21, 2013, at 1:40 PM, Drak wrote:

> The point of the reference implementation is just to make sure the specification is clear. You do not need two examples for this. The closure does that nicely. If people want to see reference implementations and the innovation that is likely to come if the PSR passes, will be in Zend, Symfony et al.
>
> You seem very attached to your code but it's superfluous to the PSR. PSR0 had a very similar closure like implementation example and it was enough for a rash of innovation after the fact.

I'm OK with a closure/function style of a general-purpose example, if it can be done; the PSR-0 example is also general-purpose.



-- pmj

[Paul Jones]

On May 21, 2013, at 1:40 PM, Drak wrote:

> On 21 May 2013 19:34, Paul Jones <pmjo...@gmail.com> wrote:
> You might not see the point, but others (for whatever reason) might be unwilling or unable to use Composer. Having a general-purpose example remains useful to those folks, whoever they might be. Indeed, I'd argue that if there's to be one example only, it should be the general-purpose one.
>
> The point of the reference implementation is just to make sure the specification is clear. You do not need two examples for this.

Heh -- in fact, PSR-0 does have two example implementations: the function, and a link to SplClassLoader.

<https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md>



-- pmj

[Drak]

On 21 May 2013 19:49, Paul Jones <pmjo...@gmail.com> wrote:Heh -- in fact, PSR-0 does have two example implementations: the function, and a link to SplClassLoader.

 <https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md>

Yes, but historically that's because it was an effort to get it included as part of the SPL stack in PHP Core. It's not the same situation now and also PHP core rejected it. We are back to the same state as before, the innovation and plethora of examples will come from the giants in the PHP community anyhow. The code only needs to illustrate the spec, not more.

Regards,

Drak 

[Paul Jones]

So, first you think PSR-0 is something to be emulated, and now it's not something to be emulated? (Sorry, could not resist. ;-)

No, the more I think about it, the more I think having the two examples is a good idea. In fact, along the lines of the more powerful general-purpose example from PSR-0, I may suggest the earlier version of the general-purpose example that shows how multiple paths can be registered for a single prefix.

Anyone else feel strongly about this one way or the other?


-- pmj

[Amy Stephen]

If examples go on the wiki, it's a lot easier to change.

[Andreas Hennings (donquixote)]

Hi Larry, others,

coming from a post I made on github (apparently the wrong place):

https://github.com/php-fig/fig-standards/issues/121

Here is the story:

1. I agree it is a bad idea to "abandon" PSR-0 (if that is even possible).

So many projects have jumped on it, killing it would "make a lot of people very angry and be widely regarded as a bad move".

Still I do strongly support PSR-X.

This means, we will be living in a world where PHP developers need to learn both patterns.

2. The "shallow directories" of the proposed PSR-X do bring a significant DX benefit.

I personally develop some (Drupal) modules with shallow directory structure (in this case based on a home-grown PEAR-like pattern), and others with a deep directory structure. The DX difference is clearly perceivable to me. (I use commandline + Nautilus + Gedit, and in all of them I perceive the DX difference of the deeply nested vs shallow directories)

3. The removal of the underscore logic could make it easier to do class discovery. But otherwise, I don't see a huge benefit.

It might be easier to learn if you don't have to care about the underscore, but then you still have to learn PSR-0 anyway, which eliminates the advantage.

4. Having one pattern with the fancy underscore logic (PSR-0) and another without (PSR-X) will feel awkward, and

5. it will make it harder to reuse the same class loader for both.

So, I would propose to keep the underscore logic from PSR-0, and only introduce the shallow directories.

This will make it easy to support PEAR, PSR-0 and PSR-X all in the same autoloader implementation. If implemented in a decent way, this will give us a measurable performance benefit over having separate class loaders for different packages. (besides, one shared autoloader can also have one shared cache mechanic)

Also note that if we keep the underscore as in PSR-0, then PSR-0 would be just a special case within PSR-X. This is a good thing.

The reusable class loader is just one implication of that.

-- Andreas (donquixote)

[Phil Sturgeon]

I used to think rocking PSR-0 and PSR-X as alternatives was for the best, but im really struggling to see now why we would do that. 

1. I agree it is a bad idea to "abandon" PSR-0 (if that is even possible).

So many projects have jumped on it, killing it would "make a lot of people very angry and be widely regarded as a bad move".

Obviously there will be an issue of confidence if PSR-0 is "killed", but that is not what anyone is suggesting. People can continue to use PSR-0, they will just notice that a newer more flexible option is available to use for their next version/project/package/whatever.

I personally do not see a downside to updating PSR-0 to say "This has been deprecated, you can use PSR-X" instead, then just make two tweaks to your composer.json and/or jiggle your structure a little bit to update things.

 

Still I do strongly support PSR-X.

This means, we will be living in a world where PHP developers need to learn both patterns.

I'm a big fan of PSR-X too, but I don't see why in a world where PSR-X exists PHP developers will forever need to learn about PSR-0. Yes if they're working on an older project, but the sooner PSR-X becomes the goto autoloader the fewer devs this will be.

 

It might be easier to learn if you don't have to care about the underscore, but then you still have to learn PSR-0 anyway, which eliminates the advantage.

It's definitely easier to understand.

 

4. Having one pattern with the fancy underscore logic (PSR-0) and another without (PSR-X) will feel awkward, and

Thats why one is deprecated and the other promoted as an alternative. The "fancy underscore logic" is becoming much less common thanks to namespaces and the proliferation of PHP 5.3. 

 

5. it will make it harder to reuse the same class loader for both.

Absolutely. People complained that have two would be bad, but in reality most folks use something that supports multiple standards, like Composer or PHPab. Having two at the same time is not an issue for autoloaders, but obviously if we promote just the one autoloader at a time new projects can just use a PSR-X compatible loader and not have to worry about PSR-0.

So, I would propose to keep the underscore logic from PSR-0, and only introduce the shallow directories.

Noooooooo! Why would we want this? We're trying to remove this silly naming oddity. Underscores are not used by modern Zend/Symfony code, even Kohana is ripping it out I believe.

 

This will make it easy to support PEAR, PSR-0 and PSR-X all in the same autoloader implementation. If implemented in a decent way, this will give us a measurable performance benefit over having separate class loaders for different packages. (besides, one shared autoloader can also have one shared cache mechanic)

 

Why not just use Composer or PHPab instead of forcing PSR-0 to maintain backwards compatibility with one of its biggest bugs and annoyances?

I feel like PSR-X should go ahead as is, and PSR-0 should be marked as deprecated. I see no benefit to keeping both alive other than political, and that is not the most important aspect of these technical specifications.

[Phil Sturgeon]

On Tuesday, 21 May 2013 02:18:20 UTC-4, Larry Garfield wrote:

I'm not even sure what deprecating PSR-0 would mean in this context.  It
effectively means a de facto "vote of no confidence" in PSR-0, since we
cannot and should not "remove" PSR-0.  It will always be there; it's
just a matter of what we talk about at conferences. :-)

We're basically just going to say, This has been deprecated, here is a super-set implementation which lets you have a more flexible folder structure.

 

As I noted before, PSR-X is a superset of PSR-0 iff none of your classes
contain underscores.  Are we willing to as a group say "we're breakin'
ur underscores if you want to stick to 'active' specs"?

New Spec = New Code.

PHP 5.3 has namespaces, and they should probably be used. If you don't use PHP 5.3 then dont use the spec that forces you to use PHP 5.3.

 

Before you knee-jerk respond "well duh, WTF are you doing not using
namespaces yet?" keep in mind there are two very important and
influential projects that still use PHP 5.2 and underscores that would
be incompatible with PSR-X: PHPUnit and Twig.  Deprecating PSR-0 while
PSR-X still removes the BC handling would be effectively saying "PHPUnit
and Twig, FIG officially tells you to piss off."

FIG officially tells you to keep on doing what you're doing, keep on using PSR-0 and keep on using underscores, but if someday in a new version you fancy using namespaces (lets be honest, its probably on the roadmap for somewhere down the line) then use PSR-X.

This is not unreasonable.

Right now the FIG is officially telling PyroCMS to fuck off, because its not even vaguely compliant with any PSR - but we're working towards it for new versions and making excellent progress. The live version of PyroCMS doesn't even use PHP 5.3, we're entirely PHP 5.2. But, we're developing towards becoming compliant over time, and that is probably what PHPUnit and Twig will do/are doing/should do, and if they don't, they're still PSR-0 compliant.

I personally don't see this as being a problem.

[Drak]

On 24 May 2013 18:09, Phil Sturgeon <em...@philsturgeon.co.uk> wrote:

Noooooooo! Why would we want this? We're trying to remove this silly naming oddity. Underscores are not used by modern Zend/Symfony code, even Kohana is ripping it out I believe.

Phil, while it may be an oddity, no-one seriously tries to name a class Test\Package\Foo_Bar_Baz 

so pedantically sure, it's an oddity, but it's no no practical relevance surely! The other approach, in order to allow PEAR class names to load would be to specify a namespace character so you can specify \ (the default) or _ when registering the namespace. e.g. 

public function addNamespace($namespace, $path, $separator = '\\')

We cannot deprecate PSR0 because PEAR classnames are a very valid part of the PHP ecosystem. PSR-X fails in this respect. There are a lot of 1st class projects that use PEAR class names and which will not be refactored to PHP 5.3 namespace, like Twig because there is no benefit to refactoring to namespaces.

Regards,

Drak

[Paul Jones]

On May 24, 2013, at 4:33 PM, Drak wrote:

> We cannot deprecate PSR0 because PEAR classnames are a very valid part of the PHP ecosystem.

Agreed. This is why PSR-X is presented as co-existing alternative to, not a replacement for, PSR-0.


-- pmj

[Andreas Hennings (donquixote)]

 

This will make it easy to support PEAR, PSR-0 and PSR-X all in the same autoloader implementation. If implemented in a decent way, this will give us a measurable performance benefit over having separate class loaders for different packages. (besides, one shared autoloader can also have one shared cache mechanic)

 

Why not just use Composer or PHPab instead of forcing PSR-0 to maintain backwards compatibility with one of its biggest bugs and annoyances?

Then it is composer that needs to provide the multiple-purpose autoloader.

Which is easier if those patterns have the same underscore logic.

But might still be reasonably possible if they don't.

[Andreas Hennings (donquixote)]

"co-existing alternative" sounds slightly different than "deprecate PSR-0"...

In the latter case we would not actively "kill" PSR-0 but expect that it will slowly fade.

[Paul Jones]

Hi all,

Several changes to the proposal have been committed and pushed, which is still found here:

<https://github.com/php-fig/fig-standards/blob/master/proposed/package-oriented-autoloader.md>

- The title of the document has changed to "Class Autoloader."

- Terminology has changed to match PHP terminology; in particular, "absolute class name" is now "fully qualified class name", and backslashes have been added to example class names throughout.

- There are various changes to the code examples; in particular, the general-purpose code example has been expanded to include the optional "multiple directories per namespace" functionality noted in the spec.

- Much as I liked the "Invader Zim" references, the proposal now uses RFC 3092-compliant example names

Besides the discussion of these changes, I do not recall any unresolved issues. (Please correct me if I'm wrong.)

Comments/questions/critique?


-- pmj

[Drak]

On 24 May 2013 23:54, Paul Jones <pmjo...@gmail.com> wrote:

Hi all,

Several changes to the proposal have been committed and pushed, which is still found here:

  <https://github.com/php-fig/fig-standards/blob/master/proposed/package-oriented-autoloader.md>

- There are various changes to the code examples; in particular, the general-purpose code example has been expanded to include the optional "multiple directories per namespace" functionality noted in the spec.

Please revert the changes marked here: https://github.com/php-fig/fig-standards/commit/09e1048a87b6ef4cd487dfa44d6ed46da92c7a28#commitcomment-3288097 or change it to remove the controversial code snip:  if (! isset()) this is something we specifically ommitted from the coding standard because there was so much disagreement. To use it in a code example creates a precedent and will only lead to more confusion and endless discussion on the list from confused users.  

Regards,

Drak

[Paul Jones]

On May 24, 2013, at 11:39 PM, Drak wrote:

> Please revert the changes marked here: https://github.com/php-fig/fig-standards/commit/09e1048a87b6ef4cd487dfa44d6ed46da92c7a28#commitcomment-3288097 or change it to remove the controversial code snip: if (! isset()) this is something we specifically ommitted from the coding standard because there was so much disagreement. To use it in a code example creates a precedent and will only lead to more confusion and endless discussion on the list from confused users.

Was there so much disagreement? I don't recall seeing it on the list. What was the particular issue?


-- pmj

[Drak]

On 25 May 2013 14:59, Paul Jones <pmjo...@gmail.com> wrote:

Was there so much disagreement?  I don't recall seeing it on the list.  What was the particular issue?

it's why it's specifically not mentioned - many people say the space is not required now because the days of black and white IDEs and emailing diffs is over (again, something usually in black and white). But how about we we just use if (isset(...) === false) { then the problem is solved without any refactoring.

Regards,

Drak

[Paul Jones]

I don't recall "space-after-!" being the source of "so much disagreement". Does anyone else?


-- pmj

[Andreas Möller]

> I don't recall "space-after-!" being the source of "so much disagreement". Does anyone else?

I think it was Rafael Dohms who mentioned it, if I recall it correctly.

I remember there was indeed some disagreement towards it.


Best regards,

Andreas

[Andreas Möller]

Hello Paul,

Besides the discussion of these changes, I do not recall any unresolved issues.  (Please correct me if I'm wrong.)

Comments/questions/critique?

I think there is a minor issue with the name of the class that is attempted to be loaded in the example - I've issued a PR for it.

Also, I think "disk" could be replaced with "file system" - I've issued a PR as well.

Best regards,

Andreas

[Beau Simensen]

From:

https://github.com/php-fig/fig-standards/wiki/Further-Style-Guide-Considerations

Mailing list link here:

https://groups.google.com/forum/?fromgroups=#!topic/php-fig/TRpoq0kdrZk

There was discussion in a PR or issue as well. Can't remember if it is linked in that thread or not. By linking these I do not mean to imply I'm personally happy with the current resolution/workaround. :)

[Phil Sturgeon]

On Saturday, 25 May 2013 00:39:59 UTC-4, Drak wrote:

 this is something we specifically ommitted from the coding standard because there was so much disagreement. To use it in a code example creates a precedent and will only lead to more confusion and endless discussion on the list from confused users.  

The only conversation I ever remember seeing was the one linked to by Beau, which I was part of. It was long after the standards were drawn up and was mostly because it felt like the decision had not specifically been made about wether if ( ! was an exception to the "no space after parenthesis" rule, as any "good readability guide" under the sun will usually suggest you wrap your bang in spaces.

Swapping to an === false would certainly avoid this conversation, and avoid condoning a specific way of doing things which is apparently still relatively controversial. 

[Phil Sturgeon]

On Friday, 24 May 2013 17:33:29 UTC-4, Drak wrote:

On 24 May 2013 18:09, Phil Sturgeon <em...@philsturgeon.co.uk> wrote:

Noooooooo! Why would we want this? We're trying to remove this silly naming oddity. Underscores are not used by modern Zend/Symfony code, even Kohana is ripping it out I believe.

Phil, while it may be an oddity, no-one seriously tries to name a class Test\Package\Foo_Bar_Baz 

so pedantically sure, it's an oddity, but it's no no practical relevance surely!

I know, I said right at the bottom of that link: "If you're using a third-party autoloader that tries to hit these files wrong then stop using that crazy autoloader, it's drunk.". People do still like to complain about how broken it is, so removing this certainly doesn't hurt.

 

We cannot deprecate PSR0 because PEAR classnames are a very valid part of the PHP ecosystem. PSR-X fails in this respect. There are a lot of 1st class projects that use PEAR class names and which will not be refactored to PHP 5.3 namespace, like Twig because there is no benefit to refactoring to namespaces.

We cannot deprecate something old, because something old still uses the old thing?

Isn't that exactly what deprecation is for?

I've said a few times im not 100% either way, im trying to make sure we end up at a logical decision. Deprecation is saying "At some point down the road you should probably be using namespaces" and having both at the same time is saying "You can pick either of these, they are both entirely valid, so its up to you to make a decision, but unless you want to pretend that _ = / you don't need PSR-0 at all."

Co-existence and deprecation is pretty much the same thing, with the only real difference being wether we suggest one thing, or two things. If we suggest two things, then why exactly are we suggesting both of them? Is it just for these underscore using projects? Keeping PSR-0 as an active recommended standard just to avoid suggesting "Hey PEAR, Twig, etc, you should probably one day consider updating to use namespaces." to me seems like a weak reason.

[Drak]

On 26 May 2013 17:01, Phil Sturgeon <em...@philsturgeon.co.uk> wrote:

Co-existence and deprecation is pretty much the same thing, with the only real difference being wether we suggest one thing, or two things. If we suggest two things, then why exactly are we suggesting both of them? Is it just for these underscore using projects? Keeping PSR-0 as an active recommended standard just to avoid suggesting "Hey PEAR, Twig, etc, you should probably one day consider updating to use namespaces." to me seems like a weak reason.

Not only that, but Twig to namespaces is probably never going to happen because it causes a whole host of BC issues and the eco system is way too big and there is simply zero benefit beyond being "hip". The autoloader could easily treat the namespace character as either \ or _ there are two options also

1. Explicitly tell it with a third param, addNamespace($namespace, $path, $nsCharacter) 

2. Require namespace characters terminate in a namespace character (which is sort of required anyhow) and auto-detect it so

    addNamespace('Twig_', $path)

    addNamespace('Zikula\\', $path)

Either way, we have an autoloader which can serve ALL needs, that is, PEAR and PHP 5.3 namespaces. All that is necessary is that we specify the PSR that registered namespaces should start with a letter and end in either \ or _ - which actually is pretty much compulsory anyhow, we just never said so before explicitly. Then we need to specify in the spec that the autoloader should map the namespace character to the filesystem using the specified character which is restricted to \ or _

Regards,

Drak

[Paul Jones]

Drak has proposed, and I have accepted, a change that uses `if (isset() === false)` instead of `if (! isset())`. It is a bit verbose but it nicely avoids any appearance of controversy.


-- pmj

[André R.]

On Tuesday, May 21, 2013 1:08:32 AM UTC+2, pmjones wrote:

Hi all,

For what it's worth, I intend to re-submit the package-oriented autoloader proposal this coming Friday. If you have fixes or suggestions, now is the time to bring them up.

I have gone back and looked through the emails that appear to have constructive criticism regarding the proposal.  The only item of note that I found was from André Romcke, which I have cobbled together from different messages. (André, please correct me if the removal of context changes your meaning.)


> Imo the spec / interface should define what should happen if you get a namespace match but missing file in that namespace, otherwise we push the ambiguity down on implementers / users. And to me, a base system like a autoloader should never cause slow downs by design, so a match not existing on disk should throw a exception, either custom one or something like Logic-/Runtime-Exception.
>
> ...
>
> Basically just returning false if file is not found in matching namespace, allowing other autoloaders in the chain to try as well, something which is not possible with exceptions.
>
> ...
>
> If needed, fix is simple, as proposed before on this list, add a flag for what to actually do on a false match can include the following options:
>
> - NS_MATCH_NO_FILE_EXCEPTION
> - NS_MATCH_NO_FILE_RETURN
> - NS_MATCH_NO_FILE_IGNORE / CONTINUE

I take this to mean that we should specify what happens if an autoloader implementation fails to find the file for a class.  There are two considerations to keep in mind:

rephrased: "we should specify what happens if an autoloader implementation fails to find the file for a class<ins> despite having a namespace match for the requested class.</ins>"

 

1. Most of the time an autoloader should not get in the way of other autoloaders when it can't find a file, e.g. by throwing exceptions.

Sure, as you see form the three snippets you have above I changed my mind to recommend it returns false by default if the condition is meet.

 

2. Sometimes an autoloader expects to be the last resort, and the implementor wants it to throw an exception when it can't find a file.

As such, I think it's reasonable to add a line to the spec, but using optional language, to indicate that the normal course is to stay out of the way, but that it is allowed if necessary.

- "Exceptions SHOULD NOT be thrown, and errors SHOULD NOT be raised, in the case of a missing file."

The wording is clumsy and probably not broad enough.  Thoughts?

+1

But that doesn't cover my concern, if it where to cover that it could be phrased like this:

- "Autoloader MAY return in the case of a missing file but matching namespace prefix, however exceptions SHOULD NOT be thrown and errors SHOULD NOT be raised." 

If it is also interesting to allow feedback if asked for (example: debug mode):

- "Autoloader MAY return in the case of a missing file but matching namespace prefix. But unless it's explicitly asked for exceptions SHOULD NOT be thrown and errors SHOULD NOT be raised."

I use MAy here as it's plenty of people that don't seem to like such a rule being a MUST, or even a SHOULD.

 

-- pmj

[André R.]

On Tuesday, May 21, 2013 8:18:20 AM UTC+2, Larry Garfield wrote:

On 05/20/2013 04:50 PM, Paul Jones wrote:
> On May 20, 2013, at 6:30 PM, Amy Stephen wrote:
>
>> Seems that there is at least some support for superseding PSR-0. I hope that is considered. In the end, I think that will be least confusing and the easiest moving forward.
> /me nods
>
> I admit, I am uneasy about replacing and deprecating PSR-0.
>
> Anyone else?
>
>
> -- pmj

I'm not even sure what deprecating PSR-0 would mean in this context.  It
effectively means a de facto "vote of no confidence" in PSR-0, since we
cannot and should not "remove" PSR-0.  It will always be there; it's 

just a matter of what we talk about at conferences. :-)

Correct, it mostly means we recommends the updated version for new implementors.

We could even have a note in PSR-X where we recommend implementers to also support PSR-0 for compatibility with older projects, or we can say PSR-X "supersedes" PSR-0 instead of using the word "deprecates".

 

As I noted before, PSR-X is a superset of PSR-0 iff none of your classes
contain underscores.  Are we willing to as a group say "we're breakin'
ur underscores if you want to stick to 'active' specs"?

Before you knee-jerk respond "well duh, WTF are you doing not using
namespaces yet?" keep in mind there are two very important and
influential projects that still use PHP 5.2 and underscores that would
be incompatible with PSR-X: PHPUnit and Twig.  Deprecating PSR-0 while
PSR-X still removes the BC handling would be effectively saying "PHPUnit
and Twig, FIG officially tells you to piss off."

I don't know about PHPUnit, but as far as I have understood Fabian from blogs and when meeting him, a future Twig 2.0 would be a namespaced version of Twig.

Also add to that my note about above recommending implementations to continue to support PSR-0 for compatibility, so the difference is *just* that we have a updatet version of a spec instead of having two competing specs.

@pmjones: The spec seems to be missing "Vendor Name" part, that and potential other missing pices from PSR-0 should probably be re-added if this in the end officially supersedes/deprecates PSR-0.

[Jason Judge]

On Monday, May 27, 2013 7:39:23 AM UTC+1, André R. wrote:

On Tuesday, May 21, 2013 1:08:32 AM UTC+2, pmjones wrote:

...

2. Sometimes an autoloader expects to be the last resort, and the implementor wants it to throw an exception when it can't find a file.

Personally, I think this is mixing two things that probably do not need to be mixed.

We have autoloaders that attempt to load classes. Each registered autoloader may:

1. Consider itself not responsible for a namespace and pass it on.
2. Consider itself a match for the namespace and try to find the class, fail to find the class, then pass it on.
3. Consider itself a match for the namespace, load the class, subsequently halting the autoloader chain.

Unless there is a reason why you would want to know exactly *which* autoloader got part-way through on step 2, I see no reason for exceptions to be raised there. Is there a use-case in which it would make sense to raise an exception rather than passing the namespace on to the next autoloader in the chain?

Instead, I would take exceptions out and handle them in "fake" autoloaders. If I want the failure to load a class to raise a specific exception that I want to handle, then a final autoloader can be registered that does nothing more than raise an error:

4. Got this far? Must be an exception, so raise it.

That step 4 could even make decisions on what exception to raise, if any, depending on the namespace. For example, if it is a core framework namespace, then raise a custom framework exception for handling on one way, otherwise assume it is a third-party package leave it for PHP to say "class not found".

So, my main point is: does the raising of exceptions need to be a function of the autoloader at all? Can the PSR-X recommendation simply state that exceptions are NOT to be raised by an autoloader; autoloaders are to either find and load a class if they can, and exit cleanly if they can't? If an implementation wants to insert its own "exception raising" steps [anywhere] into the autoloader chain, then they would be free to do so, but that would be outside the scope of PSR-X?

-- Jason

[Johannes Schmitt]

Regarding exceptions in class loaders, the Doctrine class loader has
had this functionality, and it caused a lot of headaches especially in
regard to annotations.

The problem with exceptions is that even a call to
``class_exists('Some\Class')`` could technically trigger an exception
as it also invokes all autoloaders. So, I'd highly encourage to
require that exceptions MUST NOT be raised, but really leave that to
PHP because the loader simply does not know from what context it is
invoked.

Cheers,
Johannes

> --
> 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/6503140d-a782-4b2a-bb94-340af7ebb7b0%40googlegroups.com?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Amy Stephen]

On Monday, May 27, 2013 1:59:12 AM UTC-5, André R. wrote:

@pmjones: The spec seems to be missing "Vendor Name" part, that and potential other missing pices from PSR-0 should probably be re-added if this in the end officially supersedes/deprecates PSR-0.

Andre raises a good point here.

Is there any reason not to continue to the Vendor Name requirement of the namespace within PSR-X? If not, what ensures interoperability?

[Paul M. Jones]

On May 27, 2013, at 2:49 AM, Jason Judge wrote:

> Instead, I would take exceptions out and handle them in "fake" autoloaders. If I want the failure to load a class to raise a specific exception that I want to handle, then a final autoloader can be registered that does nothing more than raise an error:
>
> 4. Got this far? Must be an exception, so raise it.
>
> That step 4 could even make decisions on what exception to raise, if any, depending on the namespace. For example, if it is a core framework namespace, then raise a custom framework exception for handling on one way, otherwise assume it is a third-party package leave it for PHP to say "class not found".

...

> So, my main point is: does the raising of exceptions need to be a function of the autoloader at all? Can the PSR-X recommendation simply state that exceptions are NOT to be raised by an autoloader; autoloaders are to either find and load a class if they can, and exit cleanly if they can't? If an implementation wants to insert its own "exception raising" steps [anywhere] into the autoloader chain, then they would be free to do so, but that would be outside the scope of PSR-X?

I really like that idea. The "final fallback" autoloader becomes a "fake autoloader" that gets called as the last one in the chain; it can examine the autoloader stack and throw, raise, log, whatever. The implementing framework/project/app can do whatever it wants there, and not have to worry about PSR compliance. Very nice.


-- pmj

[Paul Jones]

On May 27, 2013, at 1:39 AM, André R. wrote:

> But that doesn't cover my concern, if it where to cover that it could be phrased like this:
>
> - "Autoloader MAY return in the case of a missing file but matching namespace prefix, however exceptions SHOULD NOT be thrown and errors SHOULD NOT be raised."
>
> If it is also interesting to allow feedback if asked for (example: debug mode):
>
> - "Autoloader MAY return in the case of a missing file but matching namespace prefix. But unless it's explicitly asked for exceptions SHOULD NOT be thrown and errors SHOULD NOT be raised."

I'm OK with it returning something regardless of success or failure (e.g., in a testing scenario it is useful to fake a filesystem and see what the loader *would* have loaded). The big deal is to make sure that there are no side effects from the autoloader failing to find a file.

How about:

- "The registered autoloader callback MUST NOT throw exceptions, SHOULD NOT raise errors of any level, and MAY return a value."

Further thoughts?


-- pmj

[Tobias Hoffmann]

On Monday, May 27, 2013 6:23:44 PM UTC+2, pmjones wrote:

How about: 

- "The registered autoloader callback MUST NOT throw exceptions, SHOULD NOT raise errors of any level, and MAY return a value."

This sounds good, as it aligns with the default autoloader, spl_autoload().

About the error guarantee, are there any use cases where it makes sense for an autoloader to throw a hard error, i.e. E_USER_ERROR/E_ERROR?

As I understand it, an autoloader is strictly to fail gracefully, for the fallback chain to make sense.

The only case where I could think about raising an error would be a corrupt PHAR, but should that be handled at the autoloader level?

[Andreas Hennings (donquixote)]

Ok, it seems I am quite alone with my point of view.

So I will try to make my point clear enough, but I am prepared to let it drop and get over it and stop bothering you.

On Friday, May 24, 2013 11:33:29 PM UTC+2, Drak wrote:

On 24 May 2013 18:09, Phil Sturgeon <em...@philsturgeon.co.uk> wrote:

Noooooooo! Why would we want this? We're trying to remove this silly naming oddity. Underscores are not used by modern Zend/Symfony code, even Kohana is ripping it out I believe.

Phil, while it may be an oddity, no-one seriously tries to name a class Test\Package\Foo_Bar_Baz 

Seems that is the general consensus, although I don't fully agree with it.

The real question would be, IF someone names a class like that, then where would the class loader look for it?

E.g. a class named \AnimalVendor\AnimalPackage\Rabbit_White, where do we look:

PSR-0: ../src/AnimalVendor/AnimalPackage/Rabbit/White.php

PSR-X current proposal: ../src/Rabbit_White.php

PSR-X, with variation: ../src/Rabbit/White.php

OR: Do not load anything, saying that underscores are forbidden in the class name.

Of course you can still say (for a specific project) that underscores in the class name are strictly forbidden, or that they are discouraged.

Supporting those underscores (as in PSR-0) clearly has some oddities: In particular, it is not clear by looking at a file path what class you are going to find in there. You could even have two classes in the same file! This requires some attention when writing the class loader, or any class discovery code. But it can be dealt with. In practice, you will rarely run into this kind of problem.

On the other hand, the underscores can have some benefits.

E.g. you could have classes like this:

AnimalVendor\AnimalPackage\Rabbit_White

AnimalVendor\AnimalPackage\Rabbit_Grey

etc

Benefits:

- You don't need as many "use" statements within a package.

- Class names are shorter. You don't have ..\Rabbit\GreyRabbit, but just ..\Rabbit_Grey

Downside:

- Your file will be named "Grey.php", which can look odd in a text editor.

I find it pretty nice having this possibility, which was totally legitimate in PSR-0.

And major frameworks may still decide to not use underscores in their class names.

[Jason Judge]

On Tuesday, May 28, 2013 10:08:13 AM UTC+1, Andreas Hennings (donquixote) wrote:

Ok, it seems I am quite alone with my point of view.

So I will try to make my point clear enough, but I am prepared to let it drop and get over it and stop bothering you.

On Friday, May 24, 2013 11:33:29 PM UTC+2, Drak wrote:

On 24 May 2013 18:09, Phil Sturgeon <em...@philsturgeon.co.uk> wrote:

Noooooooo! Why would we want this? We're trying to remove this silly naming oddity. Underscores are not used by modern Zend/Symfony code, even Kohana is ripping it out I believe.

Phil, while it may be an oddity, no-one seriously tries to name a class Test\Package\Foo_Bar_Baz 

Seems that is the general consensus, although I don't fully agree with it.

 Just the other day I moved access to a SugarCRM REST API from "v4" to "v4_1", and guess what I wanted to name my class in order to mirror the CRM API access point? Underscores to separate words may be discouraged, but in this case there were just numbers to separate, not words, and camel-case digits is a little harder to do.

So yeah, it's an edge-case, but an instance where it would have made things a little easier for me to be using PSR-X underscores-are-not-special rather than the PSR-0 special handling of underscores.

-- JJ

-- JJ

[André R.]

On Monday, May 27, 2013 6:23:44 PM UTC+2, pmjones wrote:

It again doesn't cover the namespace prefix match, no file case in the given prefix case. 

 

-- pmj

[Paul Jones]

Hm.

Looking at it again, the case of "namespace prefix match but no file" seems like a subset of the "must not throw exceptions/errors" case. That is, the latter language covers the former, as well as a broad set of other cases. Do you think it's better to limit the language to the one case?


-- pmj

[Jason Judge]

This is a special case? It is very hard to keep track of where everyone thinks we are up to, and there is a danger of going around in circles without lines drawn in the sand.

An autoloader can match a namespace prefix and not find a matching class, and that - as far as I think we got to - is treated no differently to an autoloader not matching a namespace prefix in the first place. Does it need special mention in the PSR with respect to the raising of exceptions (or "errors" - whatever they are, if they aren't exceptions)?

For an autoloader implementation to be portable, it simply cannot raise exceptions, ever. If it does, then it will break class_exists(). If you want to raise exceptions in your own framework and break class_exists(), then that is fine and up to you, but it has nothing to do with interoperability, because it will potentially break other modules that use class_exists().

Just because one registered autoloader could not find a class in its own area that it knows about, in a given namespace that it thinks it controls, that autoloader has absolutely *no* clue that I may have further autoloaders down the chain to handle those classes. To be interoperable with my further autoloaders, then that PSR autoloader simply cannot make the assumption that it is the only autoloader to handle a namespace. Interoperability is about modules playing nicely together, and not breaking each other with assumptions that the playground is all theirs to play with.

-- Jason

[Donald Gilbert]

The other approach, in order to allow PEAR class names to load would be to specify a namespace character so you can specify \ (the default) or _ when registering the namespace. e.g. 

public function addNamespace($namespace, $path, $separator = '\\')

Now this is an interesting approach, what would be the downside of allowing a "registering package" to specify their NS separator? I realize PHP already gave us a namespace separator and that we should be using it, but I don't see a downside to this. It allows PEAR packages to be PSR-X and (somewhat) satisfies the naysayers.  

- "The registered autoloader callback MUST NOT throw exceptions, SHOULD NOT raise errors of any level, and MAY return a value." 

Good wording. +1

[Peter Cowburn]

On 27 May 2013 17:23, Paul Jones <pmjo...@gmail.com> wrote:

How about:

- "The registered autoloader callback MUST NOT throw exceptions, SHOULD NOT raise errors of any level, and MAY return a value."

Further thoughts?

Why have "and MAY return a value" at all? Do we care? What about returning "no value" (NULL)? In any case, the PHP autoload system certainly doesn't do anything with the return value, nor provide it back to us. From the previous iterations of the text, it looks like this might be left over from "… MAY return in the case of..."

[Phil Sturgeon]

On Tuesday, 28 May 2013 10:03:56 UTC-4, Donald Gilbert wrote:

The other approach, in order to allow PEAR class names to load would be to specify a namespace character so you can specify \ (the default) or _ when registering the namespace. e.g. 

public function addNamespace($namespace, $path, $separator = '\\')

Now this is an interesting approach, what would be the downside of allowing a "registering package" to specify their NS separator? I realize PHP already gave us a namespace separator and that we should be using it, but I don't see a downside to this. It allows PEAR packages to be PSR-X and (somewhat) satisfies the naysayers.  

I have nothing against this. 

There will of course be some folks trying to load \Vendor\Package\Class_Name and expect _ to equal = as well as \. I imagine \ will ALWAYS act as \ in all situations, and the "separator" is just another character which will also map to /.

[Chuck Burgess]

Good point.  Perhaps a good contextual name there would be $additionalSeparator.

[Paul Jones]

On May 28, 2013, at 9:30 AM, Peter Cowburn wrote:

> On 27 May 2013 17:23, Paul Jones <pmjo...@gmail.com> wrote:
> How about:
>
> - "The registered autoloader callback MUST NOT throw exceptions, SHOULD NOT raise errors of any level, and MAY return a value."
>
> Further thoughts?
>
>
> Why have "and MAY return a value" at all?

It came up in the conversation that autoloaders should not be returning values; this points out that it is allowed, and purely optional.


-- pmj

[Paul Jones]

I don't like it. I think the underscore thing should be relegated to PSR-0 only.

Having said that, if this becomes something that we think has way more positives than negatives, it should be limited to *only* the specified separator. I.e., there should be no allowance for mixing different separators in a single fully-qualified class name. You get *either* Foo\Bar\Baz\Qux, *or* Foo_Bar_Baz_Qux, but not Foo\Bar\Baz_Qux.


-- pmj

[Donald Gilbert]

There will of course be some folks trying to load \Vendor\Package\Class_Name and expect _ to equal = as well as \. I imagine \ will ALWAYS act as \ in all situations, and the "separator" is just another character which will also map to /.

Yes, I would agree the \ would always map to that, and then it's an `$additionalSeparator` param. But, does anyone use anything besides _ or \? I wonder if at that point we should just use a boolean for underscores in class names to map to directories or not. Then it starts to get complicated.

What I don't want is people to be able to set their separator to `s` or some crazy Unicode character. While that wouldn't be the end of the world, it really detracts from interoperability, IMO, since it opens pandora's box for confusion.

Not sure where to go with that then.

[Donald Gilbert]

Having said that, if this becomes something that we think has way more positives than negatives, it should be limited to *only* the specified separator.  I.e., there should be no allowance for mixing different separators in a single fully-qualified class name.  You get *either* Foo\Bar\Baz\Qux, *or* Foo_Bar_Baz_Qux, but not Foo\Bar\Baz_Qux.


-- pmj

I'm not sure we would have to go that route. Since Foo_Bar_Baz_Qux is the "fully qualified class name", we could still relegate the underscore to only effect the class name part of the namespace. This would retain BC with PSR-0 since underscores don't effect any part of the namespace, and would allow for PSR-0 to fit within PSR-X. While that's not a stated objective, I think it is a notable benefit.

[Peter Cowburn]

I still don't see why the PSR should, in this case, say what the autoload function MAY do.  Removing it from the PSR gives just as much information in fewer words.

Put another way, I don't like the idea of putting it into writing that implementors MAY write code that is useless (returning a value). Removing the "a value", also simply reminds people that they can return in their functions… does that really need to be part of *any* PSR?

 

-- pmj

--
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/41BC323D-59CD-4545-BF0C-60FA811FBFAF%40gmail.com?hl=en.

[Paul Jones]

I see where you're coming from. It would allow PSR-0 compliant folks to migrate to PSR-x and retain the existing practices.

However, PSR-0 did the same thing. That is, it allowed for underscores so folks could migrate to PSR-0, with the idea that the "old way" (underscores) and the "new way" (backslashes) could coexist for a period of time, and use a common naming structure (the Horde/PEAR convention). The unstated assumption was that as projects moved to PHP 5.3 they would use "real" namespace separators instead of the "pseudo" ones (underscores).

I assert that a reasonable time for migration from underscores to backslashes has passed, and that the "new way" (backslashes only) needs to be the "only way". Folks with existing PSR-0 compliant codebases using underscores in class names can continue to use PSR-0.


-- pmj

[Hari K T]

I'm not sure we would have to go that route. Since Foo_Bar_Baz_Qux is the "fully qualified class name", we could still relegate the underscore to only effect the class name part of the namespace. This would retain BC with PSR-0 since underscores don't effect any part of the namespace, and would allow for PSR-0 to fit within PSR-X. While that's not a stated objective, I think it is a notable benefit.

I agree with Donald here.

can we mention there, if you are using namespace then there is no meaning for _ ?

So we can use the old Pear conventions to load classes.

[Paul Jones]

On May 28, 2013, at 10:40 AM, Peter Cowburn wrote:

> > Why have "and MAY return a value" at all?
>
>> It came up in the conversation that autoloaders should not be returning values; this points out that it is allowed, and purely optional.
>
> I still don't see why the PSR should, in this case, say what the autoload function MAY do. Removing it from the PSR gives just as much information in fewer words.

I disagree; among other things, it raises the idea that this specific issue was discussed, and that the conversants were aware of the value (heh) of it. Given the context, I think it's worthwhile.


-- pmj

[Jordi Boggiano]

Why allow _ at all? It makes autoloaders more complex, and slower. And
that sucks hard. PSR-* style autoloaders are slow enough as it is. Let's
just keep it simple so the logic can be simple not have too many
branches because of design by committee. If you really want your files
in a sub directory then use a subnamespace instead of an underscore..

Cheers

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

[Donald Gilbert]

If it's time has passed, then I digress. We have 2 packages in the Joomla Framework that use _'s in the class name and I suppose those will either need refactoring or just remain PSR-0. 

For the curious, we use _'s in our HTML package where class names would conflict with PHP keywords, like Joomla\Html\List is Joomla\Html_List and we use it in our Crypt package due to some algorithms beginning with numbers, Joomla\Crypt\Cipher_3Des. As stated, those could be refactored or just shuffle the files around so they are no longer in a subdirectory, so it's not THAT big of a deal.

As for _'s slowing down autoloaders, the worst case scenario would, in my untested opinion, be a negligible speed difference since it's only loaded for those registered classes that tell instruct the autoloader to convert the _'s, rather than ALWAYS convert _'s as PSR-0 instructs. But Jordi, as you have more experience with autoloaders than I (with your writing of composer and supporting that) I defer. (I'm honestly not trying to sound like a dick if it's coming across that way - you really do have more experience than I do with them.)

[Phil Sturgeon]

While I don't want to throw out votes like a madman, it might be interesting if we could get a response from a large number of people on this question:

Do we care about keeping the magic meaning of _ = / for PSR-X?

It had a useful meaning for PEAR/PHPUnit and a bunch of other projects, but do we continue that old convention for new PSRs?

As Jordi says, its slower. It's only a little slower, but any speed loss needs to be justified, and if we're litterally just doing this so we don't upset the PEAR/PHPUnit/Twig type projects then... well do we care?

If it's important for us to continue the  _ = / logic then I don't have anything major against the proposed code, but I personally don't see why we should bother. 

As Don pointed out, Joomla could easily take those classes out of their subfolder and still be perfectly autoloadable under PSR-X. That's not going to kill any kittens. Somebody else pointed out Twig may well be upgrading to namesapces, so no kittens hurt there either.

[Peter Cowburn]

I beg to differ. So what if the "issue" was discussed; many, many things are discussed during the lifetime of drafting a PSR, this one included. MAY we include all of those topics in the finished document too? Given the context, I consider its presence entirely redundant.

Stick it in an FAQ or something like that, if it really is a question on the tip of everyones' tongues. The statement just screams (very quietly) of not knowing how autoload functions work.  

Returning a value does *nothing* as far as interoperability is concerned, which is supposed to be the overall goal, right?  Why state that an implementor MAY do something that is of utterly no use to anyone, not even him/herself?

Aside: how many member projects have autoload functions that *do* return a value?..

-- pmj

--
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/8708C8D2-BAA5-4097-A666-50711FC8554E%40gmail.com?hl=en.

[Paul Jones]

On May 28, 2013, at 11:53 AM, Donald Gilbert wrote:

> For the curious, we use _'s in our HTML package where class names would conflict with PHP keywords, like Joomla\Html\List is Joomla\Html_List and we use it in our Crypt package due to some algorithms beginning with numbers, Joomla\Crypt\Cipher_3Des. As stated, those could be refactored or just shuffle the files around so they are no longer in a subdirectory, so it's not THAT big of a deal.

Ah yes, I can see where having a class named List would be a problem.

At the risk of sounding like I'm telling you your business, it does sound like a rename would be the easier of the two roads (as vs continuing the special treatment of underscores in PSR-X). That's in the grand scope of all projects affected by PSR-X, of course; in Joomla land I can tell that might be troublesome.


-- pmj

[Paul Jones]

On May 28, 2013, at 12:11 PM, Peter Cowburn wrote:

>
> On 28 May 2013 16:47, Paul Jones <pmjo...@gmail.com> wrote:
>
> On May 28, 2013, at 10:40 AM, Peter Cowburn wrote:
>
> > > Why have "and MAY return a value" at all?
> >
> >> It came up in the conversation that autoloaders should not be returning values; this points out that it is allowed, and purely optional.
> >
> > I still don't see why the PSR should, in this case, say what the autoload function MAY do. Removing it from the PSR gives just as much information in fewer words.
>
> I disagree; among other things, it raises the idea that this specific issue was discussed, and that the conversants were aware of the value (heh) of it. Given the context, I think it's worthwhile.
>
> I beg to differ.

I see we continue to disagree. ;-)

Does anyone else have strong feelings about including the "MAY" language here?


-- pmj

[Drak]

On 28 May 2013 09:34, Tobias Hoffmann <th.g...@gmail.com> wrote:

This sounds good, as it aligns with the default autoloader, spl_autoload().

Point of order: it does not, spl_autoload() has no return value. 

 

About the error guarantee, are there any use cases where it makes sense for an autoloader to throw a hard error, i.e. E_USER_ERROR/E_ERROR?

As I understand it, an autoloader is strictly to fail gracefully, for the fallback chain to make sense.

The only case where I could think about raising an error would be a corrupt PHAR, but should that be handled at the autoloader level?

What @pmj has suggested simply reinforces how autoloaders should be, while allowing them to be testable if you so wanted although it might not be the best way to test an autoloader (alternative way here: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/Tests/ClassLoaderTest.php). So the real issue with "autoloaders MAY return a value" is to understand that is has exactly zero effect on the autoloading process which might indicate it's not the best way of testing your autoloader. Functional tests are better here for sure using class_exists(),

Return values are specifically ignored by the SPL autoloader because PHP core performs an internal class_exists check after each autoloader exits. If the class is not found internally (because it was never included), SPL will just notify the next autoloader until they are exhausted. If no more autoloaders exist (and the internal class_exists() is still false), PHP will issue a Fatal error. Anything to interrupt this flow will break the intention of autoloading as designed by PHP core.

As a matter of application design you may chose to place an autoloader FIRST to do things like override of classes, or you might choose to place a certain autoloader LAST to perform some action, but it's not really any concern for this PSR. An example of this is how Symfony Full Stack Framework in debugging mode will inject a debugging autoloader at the top of the stack (by getting all autoloaders, unloading them from the stack, registering the debugging autoloader [now at the top of the empty stack], and then re-registering all the previously saved autoloaders).

So I think I'm trying to say PSR-4 should not try to innovate in a way contradictory to PHP core, and if any tweaking is required to the autoloading protocol, it should be done in PHP core, not as part of the PHP-4 spec.

Regards,

Drak

[Paul Jones]

Hi all,

Per recent discussion, I have added one more item to the spec:

"The registered autoloader callback MUST NOT throw exceptions, SHOULD NOT raise errors of any level, and MAY return a value."

The last messages I read showed two objections:

- André Romcke believed it was not specific enough, and wanted to limit it only to cases when the file could not be found in a registered namespace. (I and at least one other believe it is broad enough to cover Andrés case as well as other cases.)

- Peter Cowburn believed the "MAY return a value" clause is unnecessary. (I and at least one other think it's good to point out that returned values are a reasonable occurrence.)

Does anyone continue to have strong feelings regarding the new spec item?


-- pmj

[Drak]

On 29 May 2013 15:26, Paul Jones <pmjo...@gmail.com> wrote:

"The registered autoloader callback MUST NOT throw exceptions, SHOULD NOT raise errors of any level, and MAY return a value."

The last messages I read showed two objections:

- André Romcke believed it was not specific enough, and wanted to limit it only to cases when the file could not be found in a registered namespace.  (I and at least one other believe it is broad enough to cover Andrés case as well as other cases.)

- Peter Cowburn believed the "MAY return a value" clause is unnecessary.  (I and at least one other think it's good to point out that returned values are a reasonable occurrence.)

Does anyone continue to have strong feelings regarding the new spec item?

I'd like to re-iterate, that while the MAY clause it not harmful, it's irrelevant to the PHP core SPL autoloader stack since return values are not processed. So while the clause seems to provide a way for unit testing, I've shown that it's not necessary and can be done another way. 

What I am trying to say is the "MAY clause" is of dubious value and sort of a hack. It doesn't feel comfortable for that reason.

Regards,

Drak

[Paul Jones]

On May 29, 2013, at 9:55 AM, Drak wrote:

> I'd like to re-iterate, that while the MAY clause it not harmful, it's irrelevant to the PHP core SPL autoloader stack since return values are not processed. So while the clause seems to provide a way for unit testing, I've shown that it's not necessary and can be done another way.

It may not be *necessary* to return a value for testing, but it can be *useful* to return a value for testing. (Indeed, it is in fact useful, since the tests I have for a modified general-purpose autoloader make use of a return value to see which file got loaded.)



-- pmj

[Drak]

On 29 May 2013 17:25, Paul Jones <pmjo...@gmail.com> wrote:

It may not be *necessary* to return a value for testing, but it can be *useful* to return a value for testing.  (Indeed, it is in fact useful, since the tests I have for a modified general-purpose autoloader make use of a return value to see which file got loaded.)

Indeed, but it's like the whole debacle when Doctrine and other projects made so many of their class properties private and people complained vehemently: yet, because of that, they often found better ways to do whatever they needed without making all properties protected. In the same way, SPL autoloaders really don't have a return value - so one should really test another way - and that's easily done. All I am saying is the "MAY clause" is a dirty hack and it feels uncomfortable in the specification since return values have no function in the autoloading process - ergo, testing should be achieved another way (and has by everyone so far).

Regards,

Drak

[Paul Jones]

On May 29, 2013, at 12:45 PM, Drak wrote:

> Indeed, but it's like the whole debacle when Doctrine and other projects made so many of their class properties private and people complained vehemently: yet, because of that, they often found better ways to do whatever they needed without making all properties protected. In the same way, SPL autoloaders really don't have a return value - so one should really test another way - and that's easily done. All I am saying is the "MAY clause" is a dirty hack and it feels uncomfortable in the specification since return values have no function in the autoloading process

So noted.

To reiterate: although core PHP ignores return values from registered autoloaders, *tests* for those autoloaders may find return values useful. The spec does not say "MUST NOT return a value", it says "MAY return a value" for exactly that reason: it's purely optional, and not actually needed, but may be useful in some situations.

> testing should be achieved another way (and has by everyone so far).

Testing MAY be achieved another way. ;-) And you are factually incorrect with "and has by everyone so far" -- at least one person (me!) checks a return value.

* * *

Having said all this, would we be OK with changing "MAY return a value" to "SHOULD NOT return a value" ? That leaves an allowance for testers, but emphasized that PHP itself doesn't really use it.


-- pmj

[Donald Gilbert]

SHOULD NOT is a good compromise for those who utilize the return values in testing or for other purposes (not yet thought of) while allowing them to remain technically compliant with the PSR.

[Paul Jones]

On May 29, 2013, at 1:18 PM, Donald Gilbert wrote:

> SHOULD NOT is a good compromise for those who utilize the return values in testing or for other purposes (not yet thought of) while allowing them to remain technically compliant with the PSR.

I'm willing to go with that. I have modified the PSR with that language.


-- pmj

[Donald Gilbert]

"The relative class name MUST be mapped to a sub-path by replacing namespace separators with directory separators, and the result MUST be suffixed with .php."

Should this section take into account this PHP RFC - https://wiki.php.net/rfc/phpp 

[Paul Jones]

On May 29, 2013, at 2:41 PM, Donald Gilbert wrote:

> "The relative class name MUST be mapped to a sub-path by replacing namespace separators with directory separators, and the result MUST be suffixed with .php."
>
> Should this section take into account this PHP RFC - https://wiki.php.net/rfc/phpp

Oy that's a mess. Does the PHP make note of *any* official filename extension for PHP scripts? I don't think it does.


-- pmj

[Donald Gilbert]

I don't think so either - it can be .inc .bleh or whatever, as long as you include it via an include statement or register a mimetype with the web server. So, for sake of interoperability, we should probably just stick with ".php".

Sorry for bringing that up. lol

[Jason Judge]

On Wednesday, May 29, 2013 8:41:28 PM UTC+1, Donald Gilbert wrote:

"The relative class name MUST be mapped to a sub-path by replacing namespace separators with directory separators, and the result MUST be suffixed with .php."

Should this section take into account this PHP RFC - https://wiki.php.net/rfc/phpp 

Is it just me, or does that RFC "solve" a problem that simply does not exist?

[Jeremy Lindblom]

We should definitely specify the extension in the PSR as ".php". Supporting multiple extensions would be complicated, and we already specified ".php" in PSR-0. Just leave "MUST be suffixed with .php." as is.

--
Jeremy Lindblom
PHP Software Development Engineer & Web Application Developer
Amazon Web Services – AWS SDK for PHP
@jeremeamia • https://github.com/jeremeamia

--

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/747d7007-e264-4074-8c43-65d01f9121c5%40googlegroups.com?hl=en.

[Evert Pot]

> Is it just me, or does that RFC "solve" a problem that simply does not exist?

Whether it does or doesn't, it's a bridge that can be crossed later.

Evert

[Jason Judge]

On Wednesday, May 29, 2013 9:43:35 PM UTC+1, Evert Pot wrote:

> Is it just me, or does that RFC "solve" a problem that simply does not exist?

Whether it does or doesn't, it's a bridge that can be crossed later.

True. I should have thrown my non-voting vote into the ring: dealing with one file extension, php, sounds good to me.

-- JJ

[Paul Jones]

With that, folks, I think we have a second candidate for a vote.

I have renamed the proposal to reflect its new title. Please review it here ...

<https://github.com/php-fig/fig-standards/blob/master/proposed/autoloader.md>

... and submit any final tweaks.

I expect to call for votes in a day or two, if there are no more significant issues with the proposal. (When I put it up for vote, I will change "PSR-X" to the proper PSR number.)

Thanks all.


-- pmj