Re: SplClassLoader RFC Voting phase
| From: | Lester Caine | Date: | Mon, 07 Nov 2011 18:14:20 +0000 |
| Subject: | Re: SplClassLoader RFC Voting phase | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-56125@lists.php.net to get a copy of this message | ||
guilhermeblanco@gmail.com wrote:
Hi Anthony, On Mon, Nov 7, 2011 at 3:43 PM, Anthony Ferrara<ircmaxell@gmail.com> wrote:PLEASE TRIM .............................................. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.phpActually, I just re-read the RFC again and I noticed something that's really irksome to me:Actually, it's not moving. I enlisted that RFC was still incomplete, I detailed every change that was missing and I even discussed that on the SplClassLoader thread. The comments during the discussion thread is kept. I'm just updating the RFC when I have 5 free minutes.Implementation extensionAccording to new threads in php-standards list, it seems all derived implementations have included these extensions to original support:Multiple paths per namespace Silent mode as a flagThis turns the RFC specification incompatible with current patch. Patch is going to be updated as soon as voting ends.And the following:NOTE: This implementation is not the proposed final. It requires two updates: * Multiple paths per namespace * Silent modeIf the RFC is changing (which hasn't really been done so with the exception of a few TODO notes), how can we vote on it? We're voting on the RFC which is a moving target?I make a formal motion to stop the vote at this time, stabilize and finalize the RFC and bring that finalized RFC to a vote at a later date (after at least a reduced round of discussion time has taken place). Otherwise what are we really voting on, if we think PSR-0 is important? The RFC is about putting in an implementation which as of now is not fully specified either in text or in example. How can we vote on a moving target...?Again, it's not moving.Anthony On Mon, Nov 7, 2011 at 12:23 PM, Anthony Ferrara<ircmaxell@gmail.com> wrote:-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.phpWell, with respect to that, are there any examples of where PHP currently "reserves the namespace"? I can declare functions/classes for every single disablable/PECL extension right now. So is there even a method to "reserve a namespace", yet alone enforce that in core? And with respect to the re-compile, what usually happens is that the windows builds ship with DLLs of the compiled extensions. So it's not a "part of the core compile", but an extension that can be enabled via php.ini (as is currently working with apc, mbstring, mysql, mysqli, etc). Anthony On Mon, Nov 7, 2011 at 12:09 PM, Lester Caine<lester@lsces.co.uk> wrote:Anthony Ferrara wrote:-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.phpLester, I think he was referring to something like the MySQL/bcmath/etc extension where it ships in core, but is disabled by default (requires a compile-time option). I think what you interpreted it as is basically just what PECL is for and how it works? Considering that it would basically be just `pecl install PSRClassLoader`? And at that point there's no reason for anything in the core (even reserving a namespace). That's how other extensions (even popular ones like apc) work now... Unless I'm misunderstanding what you mean...?Actually the "reserve the namespace" is probably the important piece of the jigsaw? Also while Linux 'installs' can easily 'recompile', windows builds are necessarily pre-compiled, so what is compiled in and what is available via an extension becomes more important.On Mon, Nov 7, 2011 at 11:33 AM, Lester Caine<lester@lsces.co.uk> wrote:Sebastian Bergmann wrote:3 would be acceptable if external extensions were downloaded separately to the core distribution ... but I suppose that IS 4 ;) Isn't it about time we considered a better distribution model for additions like this?1- The same as you wrote. Having it in SPL and in PHP 5.4You are missing 4: not have it at all (which would get my +1).2- Have it in PHP 5.4 as an external extension (FIG, PSR or PSG), enabled by default. 3- As an external extension, disabled by default. This would require PHP core to reserve the namespace for us.