Hello Guilherme,
2011/10/27 guilhermebla...@gmail.com <guilhermebla...@gmail.com>:
>
> PHP-Standard list is also opened.
... since a few days.
But I'll happily take the discussion there. As I feel it doesn't belong here.
Discussing PSR-0 or how it came to be is entirely off-topic (and would be
rude).
We are just discussing the C implementation now and the effects it
would have on PHP core.
>
> Already answered before. Performance is important. A native C
> implementation is much faster than a PHP code implementation.
Well, that's always a safe assumption. But a shiny benchmark would be
useful in this review.
Interesting hard fact would to be know if -for the overall framework speed-
it makes a significant difference with or without bytecode cache. Shaving
off a few milliseconds, always cool. But percentages, more fascinating.
>
>>
>> Now, PHP has case-insensitive identifiers. This includes function names,
>> class names, and not least namespaces.
>>
>> The proposed SplClassLoader would break that. Like PSR-0 it cannot satisfy
>> class name requests case-insensitively. The implementation approach is
>> indeterminate, depending on filesystem.
>>
>> Now the desire to enforce coding styles per autoloader will certainly come
>> up as post-factum rationalization here. But I'd also like to assert() that
>> this
>> creeping-in is even less acceptable from a language design point of view.
>>
>> For PHP6 there were discussions to drop BC and make identifiers case-
>> sensitive, just like in most other C-style languages. This has been shot
>> down.
>
> PSR-0 focus on a solid approach of class definition.
> But at the same time it does not touch naming conventions, except for
> file system class locations.
> If you read the mandatory section of PSR-0 [2], you'll see it's pretty
> explicit there this:
>
> - Alphabetic characters in vendor names, namespaces, and class names
> may be of any combination of lower case and upper case.
>
> So anything you said about case-sensitiveness is not broken by PSR-0.
Not sure if you understood, or just glanced over it, again.
I see that your specification _mentions_ uppercase and lowercase characters.
It falls flat on mentioning any of the implications of their presence however.
You see, the only purpose an autoloader has is to map identifiers from
the programming language onto filenames from the operating system.
And there just happen to be functional differences between the two. Namely
identifiers in PHP (like class names) are NOT case-sensitive. But filenames
on the filesystem ARE. And then, on some other systems they ARE NOT.
This is not even cursorily explained by your specification. The most basic
autoloader requirement of defining an *explicit and dependable mapping*
between the two identifier systems is not met. It only talks about class names
and namespaces, but declares the translation onto filenames only by omission.
Yes, it's obvious that it implies mixed-case filenames. But it seemingly ignores
that this is a bidirectional dependency. Once you have mixed/fixed-case files,
you CAN'T have case-insensitive class names anymore.
There's no need to start a discussion about this here, or file subsequent
explanations. There was ample opportunity to do so on the FIG mailing list
after dissident debate has been locked out. Now why the identifier handling
discrepancy never occured to anyone in two years is beyond me. But it's
also irrelevant.
SplClassLoader anyway does not provide a language-compliant autoloader.
It can fail system-dependent to load class files when the PSR-0 file naming
is followed.
The first instantiation of a class may behave differently from all subsequent:
new \Test\UserThing;
new \Test\Userthing;
Might only work in this order, or the other, or maybe on Win-systems both cases.
(Again, thanks for not debating coding standards, but PHP language
behaviour here.)
Much unlike spl_autoload() which defines the only rational mapping. (And
you know, the custom autoloaders of some more contemporary frameworks,
where this very technical side effect was at least discussed.)
> If you want to be critic, spl_autoload is a function, from the
> procedural paradigm. PHP does not have the OO implementation for the
> same, so the OO paradigm support is flawed currently in PHP. If you
> look at this perspective, an OO implementation is necessary (this is
That's a valid reason for inclusion. "Everything is better if you wrap it in
objects" is baloney, mind you. But a procedural autoloader can represent
more of an obstacle to extension.
But do you have an example handy for SplClassLoader and how/why you'd
inherit from it? Have any of the 18+ frameworks tested their autoloading
with it? (Still concerned about customizing.)
> being followed by 18+ widely adopted PHP projects. Which one would you
> choose? An individual user suggestion or a group suggestion?
Wellllllllll. I would base the decision *entirely* on technical merits. Though
wouldn't rule out popularity or a faux standard completely either.
Cheers,
mario
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
