Hey everyone,
After lengthy discussions and various opinion, we believe this issue
has been discussed at length and the PSR-0 has had this standard
effective for the past 1.5 year.
The SplClassLoader RFC has moved to "voting" stage. Please cast your
votes at https://wiki.php.net/rfc/splclassloader/vote
Thank you very much for all the interest showed so far,
--
David Coallier
I'd rather suggest to split this poll into 3 questions:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.
Cheers,
Hey everyone,
After lengthy discussions and various opinion, we believe this issue
has been discussed at length and the PSR-0 has had this standard
effective for the past 1.5 year.The SplClassLoader RFC has moved to "voting" stage. Please cast your
votes at https://wiki.php.net/rfc/splclassloader/voteThank you very much for all the interest showed so far,
--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
I agree with Guilherme on this one. The voting objective seems very vague
currently.
On Mon, Nov 7, 2011 at 12:29 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
I'd rather suggest to split this poll into 3 questions:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.Cheers,
Hey everyone,
After lengthy discussions and various opinion, we believe this issue
has been discussed at length and the PSR-0 has had this standard
effective for the past 1.5 year.The SplClassLoader RFC has moved to "voting" stage. Please cast your
votes at https://wiki.php.net/rfc/splclassloader/voteThank you very much for all the interest showed so far,
--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
--
Klaus Silveira
(011) 8564-2492
www.klaussilveira.com
Well, my only concern with splitting it into the three questions is
that the RFC specifically mentioned putting it in SPL.
So there wasn't really any discussion or RFC of either of the other
two points. While it's not really a big deal, I think that #3 at
least requires some more discussion as it does open some doors (both
good and bad) that are completely different from #1 or #2.
I don't think the voting is vague at all. The RFC was to put the
class loader into SPL. So that's what's being voted on. No more, no
less. Adding different options and votes at this point would at least
partially undermine the RFC process (as in voting without time for
comment)...
I do disagree slightly with the language though (I think it should
say "Should SplClassLoader be a feature in PHP 5.4 and in SPL" instead
of "Do you want". Because I think there are at least some people who
want it, but agrees that it doesn't belong in its current form (at
least some I've talked to). It's barely even worth pointing out, but
since I'm writing the email anyway...
Just my opinion,
Anthony Ferrara
On Mon, Nov 7, 2011 at 10:35 AM, Klaus Silveira
contato@klaussilveira.com wrote:
I agree with Guilherme on this one. The voting objective seems very vague
currently.On Mon, Nov 7, 2011 at 12:29 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:I'd rather suggest to split this poll into 3 questions:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.Cheers,
Hey everyone,
After lengthy discussions and various opinion, we believe this issue
has been discussed at length and the PSR-0 has had this standard
effective for the past 1.5 year.The SplClassLoader RFC has moved to "voting" stage. Please cast your
votes at https://wiki.php.net/rfc/splclassloader/voteThank you very much for all the interest showed so far,
--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
--
Klaus Silveira
(011) 8564-2492
www.klaussilveira.com
Well, my only concern with splitting it into the three questions is
that the RFC specifically mentioned putting it in SPL.So there wasn't really any discussion or RFC of either of the other
two points. While it's not really a big deal, I think that #3 at
least requires some more discussion as it does open some doors (both
good and bad) that are completely different from #1 or #2.I don't think the voting is vague at all. The RFC was to put the
class loader into SPL. So that's what's being voted on. No more, no
less. Adding different options and votes at this point would at least
partially undermine the RFC process (as in voting without time for
comment)...
I agree. The push has been for adding to SPL in 5.4. If the vote fails, then the RFC should be restructured to suit the needs for the next iteration.
I do disagree slightly with the language though (I think it should
say "Should SplClassLoader be a feature in PHP 5.4 and in SPL" instead
of "Do you want". Because I think there are at least some people who
want it, but agrees that it doesn't belong in its current form (at
least some I've talked to). It's barely even worth pointing out, but
since I'm writing the email anyway...Just my opinion,
Anthony Ferrara
On Mon, Nov 7, 2011 at 10:35 AM, Klaus Silveira
contato@klaussilveira.com wrote:I agree with Guilherme on this one. The voting objective seems very vague
currently.On Mon, Nov 7, 2011 at 12:29 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:I'd rather suggest to split this poll into 3 questions:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.Cheers,
Hey everyone,
After lengthy discussions and various opinion, we believe this issue
has been discussed at length and the PSR-0 has had this standard
effective for the past 1.5 year.The SplClassLoader RFC has moved to "voting" stage. Please cast your
votes at https://wiki.php.net/rfc/splclassloader/voteThank you very much for all the interest showed so far,
--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
--
Klaus Silveira
(011) 8564-2492
www.klaussilveira.com
Am 07.11.2011 15:29, schrieb guilhermeblanco@gmail.com:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.
You are missing 4: not have it at all (which would get my +1).
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
That would be even better....
Am 07.11.2011 15:29, schrieb guilhermeblanco@gmail.com:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.You are missing 4: not have it at all (which would get my +1).
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Sebastian Bergmann wrote:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.
You are missing 4: not have it at all (which would get my +1).
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?
--
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
Lester,
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...?
Anthony
Sebastian Bergmann wrote:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.You are missing 4: not have it at all (which would get my +1).
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?--
Lester Caine - G8HFLContact - 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
Anthony Ferrara wrote:
Lester,
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 justpecl 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.
Sebastian Bergmann wrote:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.You are missing 4: not have it at all (which would get my +1).
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?
--
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
Well, 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
Anthony Ferrara wrote:
Lester,
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 justpecl 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 Cainelester@lsces.co.uk wrote:
Sebastian Bergmann wrote:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.You are missing 4: not have it at all (which would get my +1).
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?--
Lester Caine - G8HFLContact - 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
Hi,
It seems we would never reach some consensus, so I prefer to stick to
the voting process.
Looks like it's another battle between core developers and framework
core developers, where the first ones don't see a benefit at all and
have to opt for a side while the other side is eagerly requesting the
feature.
Point #4 would probably turn ClassLoader useless, mainly because
shared hosting users would never have the ability to install a PECL
extension their own. That way, frameworks would still require to
bundle their own ClassLoader, turning the proposal of all this effort
useless. The idea is to have something native, not pluggable by a few.
Cheers,
Well, 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
Anthony Ferrara wrote:
Lester,
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 justpecl 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 Cainelester@lsces.co.uk wrote:
Sebastian Bergmann wrote:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.You are missing 4: not have it at all (which would get my +1).
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?--
Lester Caine - G8HFLContact - 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--
--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
I don't disagree with your assessment. I would like to add that the
framework standards group, in this case, should consider standardizing
the frameworks rather than PHP based on their needs.
There's no reason the members of your group can't reach a consensus to
develop a loader that is distributes among all member frameworks.
Sent from my iPhone
On Nov 7, 2011, at 12:37 PM, "guilhermeblanco@gmail.com"
guilhermeblanco@gmail.com wrote:
Hi,
It seems we would never reach some consensus, so I prefer to stick to
the voting process.
Looks like it's another battle between core developers and framework
core developers, where the first ones don't see a benefit at all and
have to opt for a side while the other side is eagerly requesting the
feature.Point #4 would probably turn ClassLoader useless, mainly because
shared hosting users would never have the ability to install a PECL
extension their own. That way, frameworks would still require to
bundle their own ClassLoader, turning the proposal of all this effort
useless. The idea is to have something native, not pluggable by a few.Cheers,
Well, 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
Anthony Ferrara wrote:
Lester,
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 justpecl 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.Sebastian Bergmann wrote:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.You are missing 4: not have it at all (which would get my +1).
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?--
Lester Caine - G8HFLContact - 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--
--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
Am 07.11.2011 18:36, schrieb guilhermeblanco@gmail.com:
Point #4 would probably turn ClassLoader useless
... which it is in my opinion hence my request to include that option
in the voting process.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Actually, I just re-read the RFC again and I noticed something that's
really irksome to me:
Implementation extension
According 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 flag
This 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 mode
If 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...?
Anthony
Well, 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
Anthony Ferrara wrote:
Lester,
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 justpecl 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 Cainelester@lsces.co.uk wrote:
Sebastian Bergmann wrote:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.You are missing 4: not have it at all (which would get my +1).
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?--
Lester Caine - G8HFLContact - 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
Hi Anthony,
Actually, I just re-read the RFC again and I noticed something that's
really irksome to me:Implementation extension
According 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 mode
If 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?
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.
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
Well, 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
Anthony Ferrara wrote:
Lester,
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 justpecl 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 Cainelester@lsces.co.uk wrote:
Sebastian Bergmann wrote:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.You are missing 4: not have it at all (which would get my +1).
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?--
Lester Caine - G8HFLContact - 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--
--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
guilhermeblanco@gmail.com wrote:
Hi Anthony,
Actually, I just re-read the RFC again and I noticed something that's
really irksome to me:Implementation extension
According 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 mode
If 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?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.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
Well, 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
Anthony Ferrara wrote:
Lester,
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 justpecl 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.Sebastian Bergmann wrote:
1- The same as you wrote. Having it in SPL and in PHP 5.4
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.You are missing 4: not have it at all (which would get my +1).
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?--
Lester Caine - G8HFLContact - 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--
--
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.php
I know this topic has been discussed enough, but I think one argument
was not brought up yet. The proposed solution has a bad OO design
because it violates against the "Single responsibility principle".
Another issue is that the proposed class is only one possible solution
to load PSR-0 conform classes.
I have written a blog post about this issues. Maybe someone changes his
mind after reading it.
http://blog.mohiva.com/2011/11/discussion-about-psr-0-autolaoder-in.html
Greetings,
Christian
Am 07.11.2011 14:41, schrieb David Coallier:
Hey everyone,
After lengthy discussions and various opinion, we believe this issue
has been discussed at length and the PSR-0 has had this standard
effective for the past 1.5 year.The SplClassLoader RFC has moved to "voting" stage. Please cast your
votes at https://wiki.php.net/rfc/splclassloader/voteThank you very much for all the interest showed so far,
--
David Coallier
Hey everyone,
Hi David,
After lengthy discussions and various opinion, we believe this issue
has been discussed at length and the PSR-0 has had this standard
effective for the past 1.5 year.The SplClassLoader RFC has moved to "voting" stage. Please cast your
votes at https://wiki.php.net/rfc/splclassloader/voteThank you very much for all the interest showed so far,
I'm very interesting by SplClassLoader but the RFC is not consistent.
You give an example that actually does not follow the proposed
implementation (e.g. the registerNamespace() and registerPrefix()
methods are not present in the proposed implementation).
I have a solution in Hoa (a set of libraries, please, see my signature)
for supporting multiple paths per namespace. How can I contribute
knowing that Hoa's implement follows the RFC (since it's beginning).
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at LIFC/DISC (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
Hi Ivan,
I updated the RFC a few hours ago based on a lengthy discussion in
php-standards.
It seems after these 2 years of PSR-0, all the rules are kept, but
some changes were made to the original code (the one in RFC) to
enhance the support. They are:
- Multiple paths per namespace
- Silent mode
The first one seems very useful in a component based library, while
the second is intended to not explode the class required if you have
multiple instances of ClassLoader.
I added quickly the methods ->registerNamespace() and
->registerPrefix() to RFC, but I still require to update the
SplClassLoader PHP based version.
By now, you can either look at Symfony 2, Doctrine 2 or Zend Framework
2 to see the implementation details.
Cheers,
On Mon, Nov 7, 2011 at 3:36 PM, Ivan Enderlin @ Hoa
ivan.enderlin@hoa-project.net wrote:
Hey everyone,
Hi David,
After lengthy discussions and various opinion, we believe this issue
has been discussed at length and the PSR-0 has had this standard
effective for the past 1.5 year.The SplClassLoader RFC has moved to "voting" stage. Please cast your
votes at https://wiki.php.net/rfc/splclassloader/voteThank you very much for all the interest showed so far,
I'm very interesting by SplClassLoader but the RFC is not consistent. You
give an example that actually does not follow the proposed implementation
(e.g. the registerNamespace() and registerPrefix() methods are not present
in the proposed implementation).I have a solution in Hoa (a set of libraries, please, see my signature) for
supporting multiple paths per namespace. How can I contribute knowing that
Hoa's implement follows the RFC (since it's beginning).Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/PhD. student at LIFC/DISC (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/Member of HTML and WebApps Working Group of W3C
http://w3.org/--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
Hi Ivan,
Hi,
I updated the RFC a few hours ago based on a lengthy discussion in
php-standards.
It seems after these 2 years of PSR-0, all the rules are kept, but
some changes were made to the original code (the one in RFC) to
enhance the support. They are:
- Multiple paths per namespace
- Silent mode
The first one seems very useful in a component based library, while
the second is intended to not explode the class required if you have
multiple instances of ClassLoader.
Exactly.
I added quickly the methods ->registerNamespace() and
->registerPrefix() to RFC, but I still require to update the
SplClassLoader PHP based version.
Ok.
By now, you can either look at Symfony 2, Doctrine 2 or Zend Framework
2 to see the implementation details.
The implementation is not a problem. I just said that your RFC is not
consistent and thus we can't vote for a partial RFC, it's has no sense.
I repeat my proposition to participate to this effort (PSR). How can I
contribute?
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at LIFC/DISC (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
Hi Ivan,
On Mon, Nov 7, 2011 at 3:59 PM, Ivan Enderlin @ Hoa
ivan.enderlin@hoa-project.net wrote:
Hi Ivan,
Hi,
I updated the RFC a few hours ago based on a lengthy discussion in
php-standards.
It seems after these 2 years of PSR-0, all the rules are kept, but
some changes were made to the original code (the one in RFC) to
enhance the support. They are:
- Multiple paths per namespace
- Silent mode
The first one seems very useful in a component based library, while
the second is intended to not explode the class required if you have
multiple instances of ClassLoader.Exactly.
I added quickly the methods ->registerNamespace() and
->registerPrefix() to RFC, but I still require to update the
SplClassLoader PHP based version.Ok.
By now, you can either look at Symfony 2, Doctrine 2 or Zend Framework
2 to see the implementation details.The implementation is not a problem. I just said that your RFC is not
consistent and thus we can't vote for a partial RFC, it's has no sense.I repeat my proposition to participate to this effort (PSR). How can I
contribute?
The PSR-0 went to Final Release 2 years ago.
It's not possible to change it anymore. If you find relevant items,
you can open another PSR for discussion. But be aware that autoloading
ones would be likely rejected since we already reached some standards.
=)
To participate of php-standards group, feel free to join here:
http://groups.google.com/group/php-standards
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/PhD. student at LIFC/DISC (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
Hi Ivan,
Hi :-),
The PSR-0 went to Final Release 2 years ago.
It's not possible to change it anymore. If you find relevant items,
you can open another PSR for discussion. But be aware that autoloading
ones would be likely rejected since we already reached some standards.
=)
I have nothing to say about PSR-0, I just want to participate to the effort.
To participate of php-standards group, feel free to join here:
http://groups.google.com/group/php-standards
Thanks ;-).
But well, until the RFC is inconsistent, the vote has no sense. You
should fix it quickly.
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at LIFC/DISC (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
guilhermeblanco@gmail.com wrote:
To participate of php-standards group, feel free to join here:
http://groups.google.com/group/php-standards
Not while it's not a php list ...
--
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
guilhermeblanco@gmail.com wrote:
To participate of php-standards group, feel free to join here:
http://groups.google.com/group/php-standardsNot while it's not a php list ...
+1. It would be great if PHP could host this mailing-list. It would be
an act of kindness ;-).
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at LIFC/DISC (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
On Mon, Nov 7, 2011 at 7:26 PM, Ivan Enderlin @ Hoa <
ivan.enderlin@hoa-project.net> wrote:
guilhermeblanco@gmail.com wrote:
To participate of php-standards group, feel free to join here:
http://groups.google.com/**group/php-standardshttp://groups.google.com/group/php-standardsNot while it's not a php list ...
+1. It would be great if PHP could host this mailing-list. It would be
an act of kindness ;-).
The group decided to take off from php.net AFAIK:
http://greg.chiaraquartet.net/another-200
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Mon, Nov 7, 2011 at 7:26 PM, Ivan Enderlin @ Hoa<
ivan.enderlin@hoa-project.net> wrote:guilhermeblanco@gmail.com wrote:
To participate of php-standards group, feel free to join here:
http://groups.google.com/**group/php-standardshttp://groups.google.com/group/php-standardsNot while it's not a php list ...
+1. It would be great if PHP could host this mailing-list. It would be
an act of kindness ;-).The group decided to take off from php.net AFAIK:
http://greg.chiaraquartet.net/another-200
The standards group was originally on php.net, and moved off when it was
basically thrown off for declaring that they were the self-appointed
dictators of what was Correct PHP(tm). After backing down from that,
and it was concluded that the group was not an "official PHP" anything,
it was determined that they therefore should not be on php.net. There
was a lot of drama around that whole PR fiasco.
Since then the group was basically silent for a year and a half, but has
recently started to inch back to life and discuss what to do moving
forward, and opened the list to public membership. I still think it
should remain off-PHP, because it is not an official PHP Group blessed
committee, but that doesn't mean core devs should not be involved.
If anything, the low degree of communication between "people who write
PHP" and "people who write in PHP" is, and has long been, one of PHP's
great weaknesses. I think this entire thread has shown that very well.
That is something that needs to be addressed, just as much as
inter-framework communication does. Perhaps moreso.
--Larry Garfield
If anything, the low degree of communication between "people who write
PHP" and "people who write in PHP" is, and has long been, one of PHP's
great weaknesses. I think this entire thread has shown that very well.
That is something that needs to be addressed, just as much as
inter-framework communication does. Perhaps moreso.
This is the second time someone has alluded to that. I don't see a
single core PHP developer weighing in on this thread in the way you
describe. All I see are various framework folks disagreeing with each other.
-Rasmus
Ok... I promised to complete the RFC and here I am.
I wrapped the entire idea, PHP implementation of what I'm proposing all in RFC.
If you're interested, feel free to review the document, highlight if I
missed something and update/add your votes.
http://wiki.php.net/rfc/splclassloader
Answering possible questions:
1- Why do not implement a fallback directory?
It is implemented as part of include_path lookup. Just add the
fallback directory in your include path and you're done.
2- Why not implement addAll, remove, etc?
Remove is useless. conditionally add loaders and you're done.
AddAll is ok for user land, but we focus on basic stuff, not fluffy
implementations. It can be easily done in userland.
Cheers,
If anything, the low degree of communication between "people who write
PHP" and "people who write in PHP" is, and has long been, one of PHP's
great weaknesses. I think this entire thread has shown that very well.
That is something that needs to be addressed, just as much as
inter-framework communication does. Perhaps moreso.This is the second time someone has alluded to that. I don't see a
single core PHP developer weighing in on this thread in the way you
describe. All I see are various framework folks disagreeing with each other.-Rasmus
--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
On Tue, Nov 8, 2011 at 6:17 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:
Remove is useless. conditionally add loaders and you're done.
AddAll is ok for user land, but we focus on basic stuff, not fluffy
implementations. It can be easily done in userland.
... Just like the whole rest of the class: all of it can be done in
userland with a few lines of code. So why do you stop at addAll?
Nikita
Hi Nikita,
Because there's no need to bring to C a single foreach.
Also, if you re-read the RFC, you'll see that SplClassLoader is
extendable for personalized developer needs, such as an addAll or an
APC lookup.
Cheers,
On Tue, Nov 8, 2011 at 6:17 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Remove is useless. conditionally add loaders and you're done.
AddAll is ok for user land, but we focus on basic stuff, not fluffy
implementations. It can be easily done in userland.
... Just like the whole rest of the class: all of it can be done in
userland with a few lines of code. So why do you stop at addAll?Nikita
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
On Tue, Nov 8, 2011 at 6:28 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:
Because there's no need to bring to C a single foreach.
Also, if you re-read the RFC, you'll see that SplClassLoader is
extendable for personalized developer needs, such as an addAll or an
APC lookup.
After your changes the RFC looks much more decent. I am still opposed
to the idea of this going into core (mainly because there is no
necessity), but now the implementation is somewhat more useful.
Nikita
Hi Nikita,
Thanks.
It's your option and I won't fight. But it seems my proposal is not yet 100%.
Some things I have either identified or people have reported.
1- Remove ->register() and ->unregister(), and make the
spl_autoload_register to support SplClassLoader.
I'm really +0 on this one.
But since the proposal covers an OO approach for autoload, it makes
sense the registering is pat of the available API, not in procedural
land.
2- Remove constructor prototype in interface
After some thought it makes sense, but only if interface then defines
the setMode prototype.
The background for this is supported if the user decides to enhance
the base class to support caching, requiring the injection of the
Cache layer in constructor. If it's part of the interface, it cannot
be changed.
I took this example after looking at Symfony's
ApcUniversalClassLoader:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/ApcUniversalClassLoader.php
What do you think about these 2 points?
Even if you're against the proposal, for sure you can still help to
make it consistent.
Cheers,
On Tue, Nov 8, 2011 at 6:28 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Because there's no need to bring to C a single foreach.
Also, if you re-read the RFC, you'll see that SplClassLoader is
extendable for personalized developer needs, such as an addAll or an
APC lookup.
After your changes the RFC looks much more decent. I am still opposed
to the idea of this going into core (mainly because there is no
necessity), but now the implementation is somewhat more useful.Nikita
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
For all those interested, I implemented what I referred as item 2:
<quote> After some thought it makes sense, but only if interface then defines the setMode prototype. The background for this is supported if the user decides to enhance the base class to support caching, requiring the injection of the Cache layer in constructor. If it's part of the interface, it cannot be changed. </quote>RFC is now updated covering this. If you have more questions or
suggestions, feel free to tell me.
On Tue, Nov 8, 2011 at 3:55 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:
Hi Nikita,
Thanks.
It's your option and I won't fight. But it seems my proposal is not yet 100%.
Some things I have either identified or people have reported.1- Remove ->register() and ->unregister(), and make the
spl_autoload_register to support SplClassLoader.I'm really +0 on this one.
But since the proposal covers an OO approach for autoload, it makes
sense the registering is pat of the available API, not in procedural
land.2- Remove constructor prototype in interface
After some thought it makes sense, but only if interface then defines
the setMode prototype.
The background for this is supported if the user decides to enhance
the base class to support caching, requiring the injection of the
Cache layer in constructor. If it's part of the interface, it cannot
be changed.
I took this example after looking at Symfony's
ApcUniversalClassLoader:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/ApcUniversalClassLoader.phpWhat do you think about these 2 points?
Even if you're against the proposal, for sure you can still help to
make it consistent.Cheers,
On Tue, Nov 8, 2011 at 6:28 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Because there's no need to bring to C a single foreach.
Also, if you re-read the RFC, you'll see that SplClassLoader is
extendable for personalized developer needs, such as an addAll or an
APC lookup.
After your changes the RFC looks much more decent. I am still opposed
to the idea of this going into core (mainly because there is no
necessity), but now the implementation is somewhat more useful.Nikita
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
PS: I'd love to point you all this article... this is something that
motivates me to push this RFC forward. =)
http://phpmaster.com/the-importance-of-standards/
Cheers,
On Tue, Nov 8, 2011 at 11:23 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:
For all those interested, I implemented what I referred as item 2:
<quote> After some thought it makes sense, but only if interface then defines the setMode prototype. The background for this is supported if the user decides to enhance the base class to support caching, requiring the injection of the Cache layer in constructor. If it's part of the interface, it cannot be changed. </quote>RFC is now updated covering this. If you have more questions or
suggestions, feel free to tell me.On Tue, Nov 8, 2011 at 3:55 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Hi Nikita,
Thanks.
It's your option and I won't fight. But it seems my proposal is not yet 100%.
Some things I have either identified or people have reported.1- Remove ->register() and ->unregister(), and make the
spl_autoload_register to support SplClassLoader.I'm really +0 on this one.
But since the proposal covers an OO approach for autoload, it makes
sense the registering is pat of the available API, not in procedural
land.2- Remove constructor prototype in interface
After some thought it makes sense, but only if interface then defines
the setMode prototype.
The background for this is supported if the user decides to enhance
the base class to support caching, requiring the injection of the
Cache layer in constructor. If it's part of the interface, it cannot
be changed.
I took this example after looking at Symfony's
ApcUniversalClassLoader:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/ApcUniversalClassLoader.phpWhat do you think about these 2 points?
Even if you're against the proposal, for sure you can still help to
make it consistent.Cheers,
On Tue, Nov 8, 2011 at 6:28 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Because there's no need to bring to C a single foreach.
Also, if you re-read the RFC, you'll see that SplClassLoader is
extendable for personalized developer needs, such as an addAll or an
APC lookup.
After your changes the RFC looks much more decent. I am still opposed
to the idea of this going into core (mainly because there is no
necessity), but now the implementation is somewhat more useful.Nikita
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
I don't argue with your logic and want for standards. I do question
this implementation. This is will not enforce any standards whatsoever
and I feel it serves the need for existing frameworks and
standardizing them.
I have to say, I've never heard the argument, "man, if there's one
thing I'd like to standardize in PHP, it'd definitely be autoloading
classes." No, indeed I believe this is a group of frameworks trying
to implement a standard into PHP that will help them all stay on the
same page.
After all, what better outcome than to implement the feature into PHP
rather than deciding which framework gets to "call the shots."
Oh well. I'm drunk and needed to get that off my chest.
Sent from my iPhone
On Nov 8, 2011, at 8:26 PM, "guilhermeblanco@gmail.com"
guilhermeblanco@gmail.com wrote:
PS: I'd love to point you all this article... this is something that
motivates me to push this RFC forward. =)http://phpmaster.com/the-importance-of-standards/
Cheers,
On Tue, Nov 8, 2011 at 11:23 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:For all those interested, I implemented what I referred as item 2:
<quote> After some thought it makes sense, but only if interface then defines the setMode prototype. The background for this is supported if the user decides to enhance the base class to support caching, requiring the injection of the Cache layer in constructor. If it's part of the interface, it cannot be changed. </quote>RFC is now updated covering this. If you have more questions or
suggestions, feel free to tell me.On Tue, Nov 8, 2011 at 3:55 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Hi Nikita,
Thanks.
It's your option and I won't fight. But it seems my proposal is not yet 100%.
Some things I have either identified or people have reported.1- Remove ->register() and ->unregister(), and make the
spl_autoload_register to support SplClassLoader.I'm really +0 on this one.
But since the proposal covers an OO approach for autoload, it makes
sense the registering is pat of the available API, not in procedural
land.2- Remove constructor prototype in interface
After some thought it makes sense, but only if interface then defines
the setMode prototype.
The background for this is supported if the user decides to enhance
the base class to support caching, requiring the injection of the
Cache layer in constructor. If it's part of the interface, it cannot
be changed.
I took this example after looking at Symfony's
ApcUniversalClassLoader:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/ApcUniversalClassLoader.phpWhat do you think about these 2 points?
Even if you're against the proposal, for sure you can still help to
make it consistent.Cheers,
On Tue, Nov 8, 2011 at 6:28 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Because there's no need to bring to C a single foreach.
Also, if you re-read the RFC, you'll see that SplClassLoader is
extendable for personalized developer needs, such as an addAll or an
APC lookup.
After your changes the RFC looks much more decent. I am still opposed
to the idea of this going into core (mainly because there is no
necessity), but now the implementation is somewhat more useful.Nikita
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
...
I have to say, I've never heard the argument, "man, if there's one
thing I'd like to standardize in PHP, it'd definitely be autoloading
classes." No, indeed I believe this is a group of frameworks trying
to implement a standard into PHP that will help them all stay on the
same page.
...
As a UserLand developer.
Building a new project and using libraries from various different
packages is a pain, as you need to worry about the autoloading of
each.
The push for PSR-0 has solved this, or at least gives all library
developers a heading so that new libraries that are now PSR compliant
, simply allow me to drop it in a folder and at most define a rule
that "\Such\Namespace" => "vendor/"
This makes life as a PHP developer much easier and having the standard
"valued" by PHP by having a SplClassLoader that allows any library to
not need to implement a autolaoder if no framework is present allows
for much nicer "plug and play" interaction of libraries, less work for
their developers and even less for the users.
I'm a UG leader and i work a lot on Hackathons and pet projects, my
own and guiding other people's and this is the kind of feedback i get,
not having to worry about autoloading by simply having everyone follow
a common structure is a very good outcome of the standards push. To me
this goes much further the the "framework developer" and reaches the
common developer.
And i for one think the developer is a very important part of PHP and
should be valued.
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
Rafael
This makes life as a PHP developer much easier and having the standard> "valued" by PHP by having a SplClassLoader that allows any library to> not need to implement a autolaoder if no framework is present allows> for much nicer "plug and play" interaction of libraries, less work for> their developers and even less for the users.
I would have to disagree here. When I need to use a library or a
framework or whatever, I usually just bootstrap it and done. So
instead of having to care about figuring out how to map the
namespaces, or place them appropriately, I just call the included
bootstrap.php in the library and it does the rest. You can take a
peak at an example of that here:
https://github.com/ircmaxell/PHP-CryptLib/blob/master/lib/CryptLib/bootstrap.php
If you're going for ease of use and interoperability, providing a
bootstrap file is going to be king to any autoloader/naming scheme.
Some libraries may have specific steps that it needs to do at startup
to work. That's what a bootstrap is for. Some libraries may need to
include and define functions or constants. That's what a bootstrap is
for.
Remember, libraries are more than collections of classes. They may
contain other things that autoloading just doesn't take care of.
Sure, the thought of just being able to add it to an autoloader to
take care of including the library may suffice for 90% of use cases.
But it won't work (or won't work well) enough times that I'm not sure
if it's even worth trying to reach for that goal.
Thanks,
Anthony
...
I have to say, I've never heard the argument, "man, if there's one
thing I'd like to standardize in PHP, it'd definitely be autoloading
classes." No, indeed I believe this is a group of frameworks trying
to implement a standard into PHP that will help them all stay on the
same page.
...As a UserLand developer.
Building a new project and using libraries from various different
packages is a pain, as you need to worry about the autoloading of
each.
The push for PSR-0 has solved this, or at least gives all library
developers a heading so that new libraries that are now PSR compliant
, simply allow me to drop it in a folder and at most define a rule
that "\Such\Namespace" => "vendor/"This makes life as a PHP developer much easier and having the standard
"valued" by PHP by having a SplClassLoader that allows any library to
not need to implement a autolaoder if no framework is present allows
for much nicer "plug and play" interaction of libraries, less work for
their developers and even less for the users.I'm a UG leader and i work a lot on Hackathons and pet projects, my
own and guiding other people's and this is the kind of feedback i get,
not having to worry about autoloading by simply having everyone follow
a common structure is a very good outcome of the standards push. To me
this goes much further the the "framework developer" and reaches the
common developer.And i for one think the developer is a very important part of PHP and
should be valued.Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
Rafael
This makes life as a PHP developer much easier and having the standard> "valued" by PHP by having a SplClassLoader that allows any library to> not need to implement a autolaoder if no framework is present allows> for much nicer "plug and play" interaction of libraries, less work for> their developers and even less for the users.
I would have to disagree here. When I need to use a library or a
framework or whatever, I usually just bootstrap it and done. So
instead of having to care about figuring out how to map the
namespaces, or place them appropriately, I just call the included
bootstrap.php in the library and it does the rest. You can take a
peak at an example of that here:
https://github.com/ircmaxell/PHP-CryptLib/blob/master/lib/CryptLib/bootstrap.php
You sort of prove my point here, as you actually have your own
autoloader, which in case you are PSR compliant, you would not need,
you can still use your bootstrap but no longer implement the class.
Also bootstrapping is not a solution for smaller libraries that
include one or 2 classes, having to code an autoloader for everything
is redundant. And frankly having to make sure you do requires to get
the loaders is something i would rather get rid of. The day i can code
a whole application without a single require in it will be a blast.
If you're going for ease of use and interoperability, providing a
bootstrap file is going to be king to any autoloader/naming scheme.
Some libraries may have specific steps that it needs to do at startup
to work. That's what a bootstrap is for. Some libraries may need to
include and define functions or constants. That's what a bootstrap is
for.
This depends on the size of your library, bootstrapping might not be a
requirement, and from what i see around its actually used very little.
Anything needed is attached to your application or is done in the
construct methods.
Remember, libraries are more than collections of classes. They may
contain other things that autoloading just doesn't take care of.
Libraries can be more the collections of classes, or they can be just
collection of classes. Either way my comment was directed to both
cases.
Sure, the thought of just being able to add it to an autoloader to
take care of including the library may suffice for 90% of use cases.
But it won't work (or won't work well) enough times that I'm not sure
if it's even worth trying to reach for that goal.
Thanks,Anthony
Bootstrapping and autoloading are two parts of a process, having one
done better does not exclude having the other in your library.
So a see bootstrapping as a form of configuration and preparation,
autoloading is merely a step that may or may not be in this.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
You sort of prove my point here, as you actually have your own
autoloader, which in case you are PSR compliant, you would not need,
you can still use your bootstrap but no longer implement the class.
Also bootstrapping is not a solution for smaller libraries that
include one or 2 classes, having to code an autoloader for everything
is redundant. And frankly having to make sure you do requires to get
the loaders is something i would rather get rid of. The day i can code
a whole application without a single require in it will be a blast.
I am not PSR compliant in either autoloader implementation or class
implementation. The reason is that over time I have needed (and
removed the need, but may in the future) need to use a class name as a
reserved word. Something like XOR (which is a real example). My way
of solving that was to name the class X_OR to avoid the fatal syntax
error. But I don't want it stored in /foo/bar/x/or.php. Which would
make absolutely no semantic sense. So I went with the alternative of
/foo/bar/x_or.php (which to me makes perfect sense).
And the autoloader I built is trivial. In fact, I don't use it
everywhere (out of need). In fact, I can replicate it in 10 pretty
lines of code (+1 for the comment):
https://github.com/ircmaxell/PHP-CryptLib/blob/master/test/bootstrap.php#L33
spl_autoload_register(function ($class) {
$nslen = strlen(NAMESPACE);
if (substr($class, 0, $nslen) == NAMESPACE) {
$path = substr(str_replace('\', '/', $class), $nslen);
$path = DIR . $path . '.php';
if (file_exists($path)) {
require $path;
}
}
});
This depends on the size of your library, bootstrapping might not be a
requirement, and from what i see around its actually used very little.
Anything needed is attached to your application or is done in the
construct methods.
The point is not that it's not possible, the point is that I have to
worry about it. I need to look for it in docs, or when reading about
it. The onus is put on the user to figure that out. Whereas if I
provide a bootstrap file, all I need to communicate is "just require
that bootstrap file, and today and for all time forward you'll be
fine". If you don't, and your needs change over time (due to feature
additions, etc), the way you include libraries can change. Remember,
including a library isn't just about defining an autoloader for it...
Libraries can be more the collections of classes, or they can be just
collection of classes. Either way my comment was directed to both
cases.
But your comment is only applicable to class-only libraries.
Otherwise defining an autoloader is quite simply not enough. You
would then need to include the base functions/definition files.
Whereas if you used a bootstrap file, it's abstracted away from you.
Bootstrapping and autoloading are two parts of a process, having one
done better does not exclude having the other in your library.So a see bootstrapping as a form of configuration and preparation,
autoloading is merely a step that may or may not be in this.
I agree that bootstrapping and autoloading are distinct parts. But
you're (by you, I mean most of the proponents of this RFC on this
list) playing it off like they are the same. A big rationale behind
including this is so that you can just distribute libraries and not
have to worry about bootstraping or setting up. But you do need to
worry about it. I'd MUCH rather see every single library include that
10 line closure than the maintainability nightmare of upgrading a
library to have mysterious things break because they changed the
initialization process on me. And that doesn't even consider the fact
that including this in core will 100% solidify the behavior for the
foreseeable future. So if a limitation or shortcoming is found (say
with the introduction of traits, or with a 5.5 or 6.0 feature), the
implementation is still stuck here for BC reasons. Leave it in
userland. Pear has done that for 12 years. Provide a common
implementation that gets installed with PEAR (or pyrus) and then just
require that as a dependency. It's worked this far, so why such a
push to change it...?
Additionally, take a look at Python. Python makes including a library
dirt simple. Why? Is it because it provides you with an
autoloader? Not at all (It's import method is used instead of an
autoloader, but it's distinctly different in both concept and
function). But it's also because it provides a transparent bootstrap
(the weird init.py file). Loading classes is only half the
battle. Others have solved this problem, don't ignore what they have
done...
Anthony
I am not PSR compliant in either autoloader implementation or class
implementation. The reason is that over time I have needed (and
removed the need, but may in the future) need to use a class name as a
reserved word. Something like XOR (which is a real example). My way
of solving that was to name the class X_OR to avoid the fatal syntax
error. But I don't want it stored in /foo/bar/x/or.php. Which would
make absolutely no semantic sense. So I went with the alternative of
/foo/bar/x_or.php (which to me makes perfect sense).
That is a problem in itself, as far as I know the final class name
does not do this kind of conversion on "_" but this is a naming issue
and i personally disgree with the solution, which is beside the point
and I will not comment.
And the autoloader I built is trivial. In fact, I don't use it
everywhere (out of need). In fact, I can replicate it in 10 pretty
lines of code (+1 for the comment):
https://github.com/ircmaxell/PHP-CryptLib/blob/master/test/bootstrap.php#L33spl_autoload_register(function ($class) {
$nslen = strlen(NAMESPACE);
if (substr($class, 0, $nslen) == NAMESPACE) {
$path = substr(str_replace('\', '/', $class), $nslen);
$path = DIR . $path . '.php';
if (file_exists($path)) {
require $path;
}
}
});
10 lines, 1 or 30 is still duplicated code which could be left out and
lessen the onus on the developer.
The point is not that it's not possible, the point is that I have to
worry about it. I need to look for it in docs, or when reading about
it. The onus is put on the user to figure that out. Whereas if I
provide a bootstrap file, all I need to communicate is "just require
that bootstrap file, and today and for all time forward you'll be
fine". If you don't, and your needs change over time (due to feature
additions, etc), the way you include libraries can change. Remember,
including a library isn't just about defining an autoloader for it...
If i program by PSR (which is nothing out of the ordinary) i do not
need to worry about autoloading. If i need to worry about
bootstrapping, i'm worried with initializing, not finding and
including files.
But your comment is only applicable to class-only libraries.
Otherwise defining an autoloader is quite simply not enough. You
would then need to include the base functions/definition files.
Whereas if you used a bootstrap file, it's abstracted away from you.
Its enough to load the class, what you put in bootstrapping is
initializing and i prefer libraries that don't initialize on include,
rather that initialize when initialized, that's what factories and
contruct methods or init methods are for.. not files that initialize
as soon as they are included.
I agree that bootstrapping and autoloading are distinct parts. But
you're (by you, I mean most of the proponents of this RFC on this
list) playing it off like they are the same. A big rationale behind
including this is so that you can just distribute libraries and not
have to worry about bootstraping or setting up. But you do need to
worry about it. I'd MUCH rather see every single library include that
10 line closure than the maintainability nightmare of upgrading a
library to have mysterious things break because they changed the
initialization process on me. And that doesn't even consider the fact
that including this in core will 100% solidify the behavior for the
foreseeable future. So if a limitation or shortcoming is found (say
with the introduction of traits, or with a 5.5 or 6.0 feature), the
implementation is still stuck here for BC reasons. Leave it in
userland. Pear has done that for 12 years. Provide a common
implementation that gets installed with PEAR (or pyrus) and then just
require that as a dependency. It's worked this far, so why such a
push to change it...?Additionally, take a look at Python. Python makes including a library
dirt simple. Why? Is it because it provides you with an
autoloader? Not at all (It's import method is used instead of an
autoloader, but it's distinctly different in both concept and
function). But it's also because it provides a transparent bootstrap
(the weird init.py file). Loading classes is only half the
battle. Others have solved this problem, don't ignore what they have
done...
So initializing has nothing to do with autoloading, furthermore,
autoloading should neither do nor trigger anything else other then
making the namespace available.
I'm not a PSR proposer, nor a framework leader, i'm a simple user who
has seen the benefit of the PSR and an autoloader, and what this
suggestion could do to library and class developers out there. Its a
standard, not everyone has to use it, like so many things in PHP which
are not used, but its common ground for most to be able to follow, and
that makes my life easier.
So we should agree to disagree on this one, cause bootstrapping to me
a whole separate thing which does not have to do with autoloading. To
your example, does import in python initialize or simply make
available?
Now if you want to add another layer of bootstrapping with a
init.php file.. that is something to talk about (i don't like it
though), but again.. it does not invalidade the presence of a Standard
Loader that would simplify the life of some large % of users and
developers.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
Hi,
@RDohms
What you said is pretty valid. If you're not going to use it, you vote
against it?
You may not use it, but many others can. It's a true state.
@Anthony
I already heard your points many times. I know you're against it.
I also know the voting should be reset, but before the reset, I wonder
if we can at least keep some good conversation abut possible
improvements instead of keep your opinion of being against it. Your
vote is only one, like mine, but if it gets approved, are you
satisfied with I purposed? If not, what are the improvement points?
That's what I want to hear.
@Internals
I see many people supporting my idea, even after telling everyone
after my RFC update to re-validate their votes.
Some people have changed, like Peter Cowburn and I don't blame him. He
is right. We should make it stable and then vote for it.
My wish is that we should really reset and re-open the voting stage,
but I want to make the RFC as consistent as possible. It looks like
it's getting impossible to have an average talk on this mailing list
due to the fact that people want to question about the minimum usage
instead of helping me out to consolidate it to then allow people to
give their opinions.
This attitude only makes me lose a lot of time answering questions
instead of focusing on actual RFC stability. I want to propose
something stable, I do not want to be pressured about should the RFC
exist or not. It only delays the real voting results. What I can do to
address this?
Thanks,
I am not PSR compliant in either autoloader implementation or class
implementation. The reason is that over time I have needed (and
removed the need, but may in the future) need to use a class name as a
reserved word. Something like XOR (which is a real example). My way
of solving that was to name the class X_OR to avoid the fatal syntax
error. But I don't want it stored in /foo/bar/x/or.php. Which would
make absolutely no semantic sense. So I went with the alternative of
/foo/bar/x_or.php (which to me makes perfect sense).That is a problem in itself, as far as I know the final class name
does not do this kind of conversion on "_" but this is a naming issue
and i personally disgree with the solution, which is beside the point
and I will not comment.And the autoloader I built is trivial. In fact, I don't use it
everywhere (out of need). In fact, I can replicate it in 10 pretty
lines of code (+1 for the comment):
https://github.com/ircmaxell/PHP-CryptLib/blob/master/test/bootstrap.php#L33spl_autoload_register(function ($class) {
$nslen = strlen(NAMESPACE);
if (substr($class, 0, $nslen) == NAMESPACE) {
$path = substr(str_replace('\', '/', $class), $nslen);
$path = DIR . $path . '.php';
if (file_exists($path)) {
require $path;
}
}
});10 lines, 1 or 30 is still duplicated code which could be left out and
lessen the onus on the developer.The point is not that it's not possible, the point is that I have to
worry about it. I need to look for it in docs, or when reading about
it. The onus is put on the user to figure that out. Whereas if I
provide a bootstrap file, all I need to communicate is "just require
that bootstrap file, and today and for all time forward you'll be
fine". If you don't, and your needs change over time (due to feature
additions, etc), the way you include libraries can change. Remember,
including a library isn't just about defining an autoloader for it...If i program by PSR (which is nothing out of the ordinary) i do not
need to worry about autoloading. If i need to worry about
bootstrapping, i'm worried with initializing, not finding and
including files.But your comment is only applicable to class-only libraries.
Otherwise defining an autoloader is quite simply not enough. You
would then need to include the base functions/definition files.
Whereas if you used a bootstrap file, it's abstracted away from you.Its enough to load the class, what you put in bootstrapping is
initializing and i prefer libraries that don't initialize on include,
rather that initialize when initialized, that's what factories and
contruct methods or init methods are for.. not files that initialize
as soon as they are included.I agree that bootstrapping and autoloading are distinct parts. But
you're (by you, I mean most of the proponents of this RFC on this
list) playing it off like they are the same. A big rationale behind
including this is so that you can just distribute libraries and not
have to worry about bootstraping or setting up. But you do need to
worry about it. I'd MUCH rather see every single library include that
10 line closure than the maintainability nightmare of upgrading a
library to have mysterious things break because they changed the
initialization process on me. And that doesn't even consider the fact
that including this in core will 100% solidify the behavior for the
foreseeable future. So if a limitation or shortcoming is found (say
with the introduction of traits, or with a 5.5 or 6.0 feature), the
implementation is still stuck here for BC reasons. Leave it in
userland. Pear has done that for 12 years. Provide a common
implementation that gets installed with PEAR (or pyrus) and then just
require that as a dependency. It's worked this far, so why such a
push to change it...?Additionally, take a look at Python. Python makes including a library
dirt simple. Why? Is it because it provides you with an
autoloader? Not at all (It's import method is used instead of an
autoloader, but it's distinctly different in both concept and
function). But it's also because it provides a transparent bootstrap
(the weird init.py file). Loading classes is only half the
battle. Others have solved this problem, don't ignore what they have
done...So initializing has nothing to do with autoloading, furthermore,
autoloading should neither do nor trigger anything else other then
making the namespace available.I'm not a PSR proposer, nor a framework leader, i'm a simple user who
has seen the benefit of the PSR and an autoloader, and what this
suggestion could do to library and class developers out there. Its a
standard, not everyone has to use it, like so many things in PHP which
are not used, but its common ground for most to be able to follow, and
that makes my life easier.So we should agree to disagree on this one, cause bootstrapping to me
a whole separate thing which does not have to do with autoloading. To
your example, does import in python initialize or simply make
available?Now if you want to add another layer of bootstrapping with a
init.php file.. that is something to talk about (i don't like it
though), but again.. it does not invalidade the presence of a Standard
Loader that would simplify the life of some large % of users and
developers.--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
Hi!
This attitude only makes me lose a lot of time answering questions
instead of focusing on actual RFC stability. I want to propose
something stable, I do not want to be pressured about should the RFC
exist or not. It only delays the real voting results. What I can do to
address this?
I would concentrate on cleaning up RFC and bringing it to some state
that is stable and that has some consensus behind it. Right now I see
many people are against it. So I would address the concerns raised
(provided it's possible), refine all unclear points and then maybe try
again.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi Stas,
Hi!
This attitude only makes me lose a lot of time answering questions
instead of focusing on actual RFC stability. I want to propose
something stable, I do not want to be pressured about should the RFC
exist or not. It only delays the real voting results. What I can do to
address this?I would concentrate on cleaning up RFC and bringing it to some state that is
stable and that has some consensus behind it. Right now I see many people
are against it. So I would address the concerns raised (provided it's
possible), refine all unclear points and then maybe try again.
The RFC is actually clean and implements PSR-0, it has been discussed
and approved by many PHP frameworks or projects. We are hiding
ourselves in the sand if we don't see that. Arguing about PSR-0 is
fine but that's not the place to do it. And as PSR-0 is already
approved, poeple with issues should bring them in the PSR-0 discussion
channel, for the next version of PSR.
But blocking the only thing so many PHP projects have ever agreed on
is a major mistake. And it is a political and religious choice
(religious as in "php does not enforce standard"). Even for something
that does not enforce anything if not used.
And as far as I can see, the RFC is approved as of now.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi Stas,
On Thu, Nov 10, 2011 at 8:17 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:Hi!
This attitude only makes me lose a lot of time answering questions
instead of focusing on actual RFC stability. I want to propose
something stable, I do not want to be pressured about should the RFC
exist or not. It only delays the real voting results. What I can do to
address this?I would concentrate on cleaning up RFC and bringing it to some state
that is
stable and that has some consensus behind it. Right now I see many people
are against it. So I would address the concerns raised (provided it's
possible), refine all unclear points and then maybe try again.The RFC is actually clean and implements PSR-0, it has been discussed
and approved by many PHP frameworks or projects. We are hiding
ourselves in the sand if we don't see that. Arguing about PSR-0 is
fine but that's not the place to do it. And as PSR-0 is already
approved, poeple with issues should bring them in the PSR-0 discussion
channel, for the next version of PSR.But blocking the only thing so many PHP projects have ever agreed on
is a major mistake. And it is a political and religious choice
(religious as in "php does not enforce standard"). Even for something
that does not enforce anything if not used.And as far as I can see, the RFC is approved as of now.
So if the wast majority of the community would use/depend on features like
magic_quotes or safe_mode, the that justifies adding/keeping those features
even though if from the technically point of view they are flawed?
I'm just playing the Devil's advocate here.
Btw: when will we close the votes? I didn't had time to catch up with the
changes in the RFC, so my vote is based on an earlier version, I would like
to re-read and if the previous concerns are resolved I would like to change
my vote, so it would be good to know in advance when will we close the
voting.
thanks
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
But blocking the only thing so many PHP projects have ever agreed on
is a major mistake. And it is a political and religious choice
(religious as in "php does not enforce standard"). Even for something
that does not enforce anything if not used.
Nobody's blocking anything. I don't understand how not having particular
class loader implemented in C and released with PHP source - which would
not be useful for frameworks anyway for a pretty long time because they
would have to support 5.3 for years - is "blocking" anything.
Right now I personally am not sure this belongs in C code at all - I'd
much rather have standard-library type component in PHP, which is much
easier to reuse and maintain compatibility and upgrade. That's only my
opinion though...
And as far as I can see, the RFC is approved as of now.
It's 19:17 and the vote is not even closed - that's what we are calling
consensus now? because it looks like exactly what I was afraid of when
we discussed voting starts to happen - the "I have 50%+1, I won, anyone
who doesn't like it can shut up" phenomenon, which can't be healthy.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Nobody's blocking anything.
See the votes, that's pretty much us vs the rest. And it is not the
1st time (happened already in the past before we had the RFC process,
so it will become more and more visible.
And as far as I can see, the RFC is approved as of now.
It's 19:17 and the vote is not even closed -
hence the "as of now". But you did not give it a single change by
killing it with RC1 without the patch, while we agreed on getting it
in if it was approved.
that's what we are calling
consensus now? because it looks like exactly what I was afraid of when we
discussed voting starts to happen - the "I have 50%+1, I won, anyone who
doesn't like it can shut up" phenomenon, which can't be healthy.
As per definition there will always have 50% +1, or 60% +1, or
whatever else. As of language changes it requires more than 50%+1. But
what I call a consensus is to have the ability to non legacy
developers to propose something and gets it accepted even if we, the
legacy developers, stick to our old ideas and views. And so far it
works well, due to developers changing their minds with the time and
new contributors.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
2011/11/10 Pierre Joye pierre.php@gmail.com:
hi Stas,
Hi!
This attitude only makes me lose a lot of time answering questions
instead of focusing on actual RFC stability. I want to propose
something stable, I do not want to be pressured about should the RFC
exist or not. It only delays the real voting results. What I can do to
address this?I would concentrate on cleaning up RFC and bringing it to some state that is
stable and that has some consensus behind it. Right now I see many people
are against it. So I would address the concerns raised (provided it's
possible), refine all unclear points and then maybe try again.The RFC is actually clean and implements PSR-0, it has been discussed
and approved by many PHP frameworks or projects. We are hiding
ourselves in the sand if we don't see that. Arguing about PSR-0 is
fine but that's not the place to do it. And as PSR-0 is already
approved, poeple with issues should bring them in the PSR-0 discussion
channel, for the next version of PSR.
You're mixing stuff here.
"RFC on PSR-0 support into PHP status" != "PSR-0 status"
There is indeed no point discussing PSR-0 here, this is a standard (de
facto or not, I don't care).
However, how PSR-0 might be introduced into PHP, for those who uses
it, is for sure not ready yet and certainly not approved!
I'm all for having a PSR-0 loader in the core of PHP, but if I voted
"No", that is because I think the RFC is not ready yet.
But blocking the only thing so many PHP projects have ever agreed on
is a major mistake. And it is a political and religious choice
(religious as in "php does not enforce standard"). Even for something
that does not enforce anything if not used.
Some are blocking because they kinda feel forced if this is introduced.
Ignore those, PHP wouldn't have bundled ext/mysql for the same reasons
about 15 years ago.
I guess that some voted "No" because of lack of consensus.
There is a real need to clarify some of the valid concerns that have
been addressed regarding the API proposed.
And as far as I can see, the RFC is approved as of now.
That is simply not true.
Patrick
On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT
patrickallaert@php.net wrote:
You're mixing stuff here.
"RFC on PSR-0 support into PHP status" != "PSR-0 status"
I do not. But we are confusing our old vision and what users are looking for.
However, how PSR-0 might be introduced into PHP, for those who uses
it, is for sure not ready yet and certainly not approved!I'm all for having a PSR-0 loader in the core of PHP, but if I voted
"No", that is because I think the RFC is not ready yet.
That's a single non intrusive function representing what has been
approved by many projects. Nobody is forced to use it nor does it
enforce anything.
Some are blocking because they kinda feel forced if this is introduced.
Ignore those, PHP wouldn't have bundled ext/mysql for the same reasons
about 15 years ago.I guess that some voted "No" because of lack of consensus.
What amazes me is this exact argument. We never had, in the whole PHP
history, so many leading projects agreeing on something, together and
propose it to the core. I, for one, have been waiting for that to
happen for years (PEAR, etc.), and now that it is happening, what do
we do? 'No thanks', for whatever reasons. That's so wrong.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Comments are inline.
On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT
patrickallaert@php.net wrote:You're mixing stuff here.
"RFC on PSR-0 support into PHP status" != "PSR-0 status"I do not. But we are confusing our old vision and what users are looking for.
However, how PSR-0 might be introduced into PHP, for those who uses
it, is for sure not ready yet and certainly not approved!I'm all for having a PSR-0 loader in the core of PHP, but if I voted
"No", that is because I think the RFC is not ready yet.That's a single non intrusive function representing what has been
approved by many projects. Nobody is forced to use it nor does it
enforce anything.Some are blocking because they kinda feel forced if this is introduced.
Ignore those, PHP wouldn't have bundled ext/mysql for the same reasons
about 15 years ago.I guess that some voted "No" because of lack of consensus.
What amazes me is this exact argument. We never had, in the whole PHP
history, so many leading projects agreeing on something, together and
propose it to the core. I, for one, have been waiting for that to
happen for years (PEAR, etc.), and now that it is happening, what do
we do? 'No thanks', for whatever reasons. That's so wrong.
Touching the subject that Pierre is rightly pointing out:
-- Useless? Getting in the way?
- This is an additional and optional class to SPL. The SPL
extension itself is even optional there is no enforcing here. The SPL
itself is a collection of classes for very specific and different use
cases, it's not getting in the way of anything. We are not bringing
PSR into PHP, we are taking the concept we discovered that was highly
successful, and taking that to PHP to continue to be even more
successful.
-- Small "pet projects" or small subset developers?
- This isn't a "bunch" of developers, this is a bunch of the largest
used PHP libraries in the world (ZF, Symfony, Doctrine, PPI, Drupal),
count up how many people are using these libraries, building plugins,
integrating parts of them together to make great tools and give PHP a
great name that's in the millions. Only a few people in this scene
have a voice, but they're voicing on behalf of the millions f
developers and hundreds of companies that rely on there being
consistency.
Like Pierre said; it's very rare that you get so many leading projects
able to agree on something that lets them all communicate together and
share resources. Isn't that itself considerable enough to say "Ok here
it is, lets see where this takes PHP libraries". This autoloading is
actually strengthening the unity of the PHP community and its
developer base. With a language as loose as PHP saying "You can do
things your own way", for business you need consistency and
compatibility and that's what is going to happen if we decide to make
a SplClassLoader.
-
Go back ~5 years ago, PHP itself was big, but frameworks were just
starting to get used. Now jump forward to today, what do you see? The
majority of job requirements and software requirements for PHP
applications is that they know ZF, Symfony, Doctrine. Why? Because
it's a highly consistent package of tools that are being used to build
great apps for the world. They agreed on their own class loader, so
why not expand that success to any future library that's make and
optionally decides to become part of that eco-system. -
How can we progress from what has evolved from point #3 above ? We
must provide ways that help the major libraries work in the same
direction, how can we do that? By enabling a class in our SPL library
giving more consistency, what does this mean for new projects? By
adhearing to SplClassLoader (a well accepted and generalised way of
class mapping) it allows your new project to enter the prolific
eco-system. So regardless of the author, or language, if it speaks PSR
(or now, the default SplClassLoader mapping) it can be truly plug and
play into thousands of applications loving this standard. -
Inclusion into core? There are perfectly good reasons why it's
being moved into core that's bundled with the major PHP distribution.
If it was its own EXT, then it wouldn't be a convenient way to code,
as it creates a dependency to install pecl libraries which isn't
always within scope for users/companies/developers. If it is its own
extension, then the push for it to be more accepted and widely used
would have been a waste of time, only a small few are willing to go
that extra mile, they are going to build their library to be the most
compatible out of the box and thus we're requesting recognised
justification for SPL inclusion. -
Naming? The name 'psr' doesn't belong in PHP, it's a group of
project leaders sitting down to see what we can do to make the PHP
eco-system better. Much like an internals meeting but still in
userland. The right place, and more extensible place in PHP that new
features are going into, I would say, is SPL. It makes sense, it feels
right and it has a good ~4 year proven track record for success. If
the PHP language/team can recognise this and welcome these
consistencies everybody is going to move forward in strength, rather
than diverge.
With all the above said, even if you personally don't use PSR, or any
of the above libraries. This vote isn't about what you use, it's about
the majority of the PHP developer base. Even if you personally don't
use it, it doesn't mean you should vote against it, considering
you're not even being affected by the addition rather than
modification to PHP.
Thanks, I hope we can wipe the votes and have people take a second
look at what we're proposing here.
Regards,
Paul Dragoonis.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
- This isn't a "bunch" of developers, this is a bunch of the largest> used PHP libraries in the world (ZF, Symfony, Doctrine, PPI, Drupal),
Ok, I have to say it... You're a group of people who have done great
things. Good for you. Get over it. Stop trying to use that as a
justification or assertion of power. We all know the importance of
what all of the projects has done. But you're asserting it and
flaunting it like it's a badge of honor. Please stop. It disrespects
each and every person who has contributed to those projects, or any
project that was not included in the "standards group". It's also
disrespectful to every single person who has contributed to PHP
because they way you're saying it is "we're more important than you,
because we're big".
This is not a place to talk about who decided what, but technical
merits. God himself could have made a decision, but if it's not
right, that doesn't mean it should be implemented.
Please stop trying to turn this into a political battle...
Anthony
Comments are inline.
On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT
patrickallaert@php.net wrote:You're mixing stuff here.
"RFC on PSR-0 support into PHP status" != "PSR-0 status"I do not. But we are confusing our old vision and what users are looking for.
However, how PSR-0 might be introduced into PHP, for those who uses
it, is for sure not ready yet and certainly not approved!I'm all for having a PSR-0 loader in the core of PHP, but if I voted
"No", that is because I think the RFC is not ready yet.That's a single non intrusive function representing what has been
approved by many projects. Nobody is forced to use it nor does it
enforce anything.Some are blocking because they kinda feel forced if this is introduced.
Ignore those, PHP wouldn't have bundled ext/mysql for the same reasons
about 15 years ago.I guess that some voted "No" because of lack of consensus.
What amazes me is this exact argument. We never had, in the whole PHP
history, so many leading projects agreeing on something, together and
propose it to the core. I, for one, have been waiting for that to
happen for years (PEAR, etc.), and now that it is happening, what do
we do? 'No thanks', for whatever reasons. That's so wrong.Touching the subject that Pierre is rightly pointing out:
-- Useless? Getting in the way?
- This is an additional and optional class to SPL. The SPL
extension itself is even optional there is no enforcing here. The SPL
itself is a collection of classes for very specific and different use
cases, it's not getting in the way of anything. We are not bringing
PSR into PHP, we are taking the concept we discovered that was highly
successful, and taking that to PHP to continue to be even more
successful.-- Small "pet projects" or small subset developers?
- This isn't a "bunch" of developers, this is a bunch of the largest
used PHP libraries in the world (ZF, Symfony, Doctrine, PPI, Drupal),
count up how many people are using these libraries, building plugins,
integrating parts of them together to make great tools and give PHP a
great name that's in the millions. Only a few people in this scene
have a voice, but they're voicing on behalf of the millions f
developers and hundreds of companies that rely on there being
consistency.Like Pierre said; it's very rare that you get so many leading projects
able to agree on something that lets them all communicate together and
share resources. Isn't that itself considerable enough to say "Ok here
it is, lets see where this takes PHP libraries". This autoloading is
actually strengthening the unity of the PHP community and its
developer base. With a language as loose as PHP saying "You can do
things your own way", for business you need consistency and
compatibility and that's what is going to happen if we decide to make
a SplClassLoader.
Go back ~5 years ago, PHP itself was big, but frameworks were just
starting to get used. Now jump forward to today, what do you see? The
majority of job requirements and software requirements for PHP
applications is that they know ZF, Symfony, Doctrine. Why? Because
it's a highly consistent package of tools that are being used to build
great apps for the world. They agreed on their own class loader, so
why not expand that success to any future library that's make and
optionally decides to become part of that eco-system.How can we progress from what has evolved from point #3 above ? We
must provide ways that help the major libraries work in the same
direction, how can we do that? By enabling a class in our SPL library
giving more consistency, what does this mean for new projects? By
adhearing to SplClassLoader (a well accepted and generalised way of
class mapping) it allows your new project to enter the prolific
eco-system. So regardless of the author, or language, if it speaks PSR
(or now, the default SplClassLoader mapping) it can be truly plug and
play into thousands of applications loving this standard.Inclusion into core? There are perfectly good reasons why it's
being moved into core that's bundled with the major PHP distribution.
If it was its own EXT, then it wouldn't be a convenient way to code,
as it creates a dependency to install pecl libraries which isn't
always within scope for users/companies/developers. If it is its own
extension, then the push for it to be more accepted and widely used
would have been a waste of time, only a small few are willing to go
that extra mile, they are going to build their library to be the most
compatible out of the box and thus we're requesting recognised
justification for SPL inclusion.Naming? The name 'psr' doesn't belong in PHP, it's a group of
project leaders sitting down to see what we can do to make the PHP
eco-system better. Much like an internals meeting but still in
userland. The right place, and more extensible place in PHP that new
features are going into, I would say, is SPL. It makes sense, it feels
right and it has a good ~4 year proven track record for success. If
the PHP language/team can recognise this and welcome these
consistencies everybody is going to move forward in strength, rather
than diverge.With all the above said, even if you personally don't use PSR, or any
of the above libraries. This vote isn't about what you use, it's about
the majority of the PHP developer base. Even if you personally don't
use it, it doesn't mean you should vote against it, considering
you're not even being affected by the addition rather than
modification to PHP.Thanks, I hope we can wipe the votes and have people take a second
look at what we're proposing here.Regards,
Paul Dragoonis.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
What amazes me is this exact argument. We never had, in the whole PHP
history, so many leading projects agreeing on something, together and
propose it to the core. I, for one, have been waiting for that to
happen for years (PEAR, etc.), and now that it is happening, what do
we do? 'No thanks', for whatever reasons. That's so wrong.
Actually it's the second. The first big agreement was GoPHP5, which is
how we finally buried PHP 4. :-) Sadly that momentum didn't continue
(in part my fault).
--Larry Garfield
2011/11/10 Pierre Joye pierre.php@gmail.com:
On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT
Some are blocking because they kinda feel forced if this is introduced.
Ignore those, PHP wouldn't have bundled ext/mysql for the same reasons
about 15 years ago.I guess that some voted "No" because of lack of consensus.
What amazes me is this exact argument. We never had, in the whole PHP
history, so many leading projects agreeing on something, together and
propose it to the core. I, for one, have been waiting for that to
happen for years (PEAR, etc.), and now that it is happening, what do
we do? 'No thanks', for whatever reasons. That's so wrong.
The many "leading projects agreeing on something" is the PSR-0
standard[1] and NOT about how it might/should be implemented in PHP
[2], nor about a possible native implementation[3].
Repeating some other's concerns, including mine:
- Registering/Unregistering: What about removing
SplAutoloader/SplClassLoader [un]register() in favor of changing
spl_autoload_register()to accept an SplAutoloader object or
implementing __invoke()? - SplClassLoader: Name does not reflect the PSR-0 standard at all,
nor are autoloader just for "classes" (interfaces, traits,...) =>
SplPsr0Autoloader? In any case, that class is misnamed. - Would the implementation be friendly for (namespaced?) function
autoloading? (Doesn't exist yet but has been raised multiple times.
Might be wise to consider it while developing an "SplAutoloader"
interface) - Should INI directives be considered for configuration
(default_autoloader_class, default_autoloader_path,
psr0_autoload_file_extension, psr0_include_path, ...) - Included/Enabled by default?
- The different methods of SplClassLoader might be defined in
separate traits for higher reusability.
Can those technical concerns, as well as all the ones I missed, not
involving the standard, be addressed prior to voting?
Some "No" votes might then probably be turned into "Yes".
Cheers,
Patrick
[1] https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md
[2] https://gist.github.com/221634
[3] https://gist.github.com/1310352
Hi,
I'm fine with the most of the implementation. But I have some
suggestions to optimize it.
- The interface should be named SplClassLoader and the register and
unregister methods should be removed.
It should be possible to define class loader implementations without
registering them as autoloader because autoloading isn't the only way to
load classes. A class loader could as example return the ReflectionClass
instance for the loaded class. I think the current interface is to
restrictive in this case. As compromise it would be possible to define a
SplClassAutoloader interface too. This interface extends the
SplClassLoader interface and defines the methods register and
unregister.
interface SplClassAutoloader extends SplClassLoader {
public function register($prepend = false);
public function unregister();
}
As a side note, the two interfaces doesn't violate the Single
responsibility principle.
I know the reference implementation is named as SplClassLoader but this
should be renamed into SplDefaultAutoloader or SplPsrAutoloader if
implements the SplClassAutoloader or as SplPsrClassloader or
SplDefaultClassloader if implements the SplClassLoader interface.
- The function
spl_autoload_register()should accept all
SplClassLoader implementations.
I know it's already possible with the following syntax:
$classLoader = new MyCustomClassLoader();
spl_autoload_register(array($classLoader, 'load'));
But the following syntax seems more consistent to me:
$classLoader = new MyCustomClassLoader();
spl_autoload_register($classLoader);
Christian
Am 09.11.2011 02:23, schrieb guilhermeblanco@gmail.com:
For all those interested, I implemented what I referred as item 2:
<quote> After some thought it makes sense, but only if interface then defines the setMode prototype. The background for this is supported if the user decides to enhance the base class to support caching, requiring the injection of the Cache layer in constructor. If it's part of the interface, it cannot be changed. </quote>RFC is now updated covering this. If you have more questions or
suggestions, feel free to tell me.On Tue, Nov 8, 2011 at 3:55 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Hi Nikita,
Thanks.
It's your option and I won't fight. But it seems my proposal is not
yet 100%.
Some things I have either identified or people have reported.1- Remove ->register() and ->unregister(), and make the
spl_autoload_register to support SplClassLoader.I'm really +0 on this one.
But since the proposal covers an OO approach for autoload, it makes
sense the registering is pat of the available API, not in procedural
land.2- Remove constructor prototype in interface
After some thought it makes sense, but only if interface then
defines
the setMode prototype.
The background for this is supported if the user decides to enhance
the base class to support caching, requiring the injection of the
Cache layer in constructor. If it's part of the interface, it cannot
be changed.
I took this example after looking at Symfony's
ApcUniversalClassLoader:What do you think about these 2 points?
Even if you're against the proposal, for sure you can still help to
make it consistent.Cheers,
On Tue, Nov 8, 2011 at 3:39 PM, Nikita Popov
nikita.ppv@googlemail.com wrote:On Tue, Nov 8, 2011 at 6:28 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Because there's no need to bring to C a single foreach.
Also, if you re-read the RFC, you'll see that SplClassLoader is
extendable for personalized developer needs, such as an addAll or
an
APC lookup.
After your changes the RFC looks much more decent. I am still
opposed
to the idea of this going into core (mainly because there is no
necessity), but now the implementation is somewhat more useful.Nikita
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
Hi,
Hi Christian :-),
I'm fine with the most of the implementation. But I have some
suggestions to optimize it.
- The interface should be named SplClassLoader and the register and
unregister methods should be removed.It should be possible to define class loader implementations without
registering them as autoloader because autoloading isn't the only way
to load classes. A class loader could as example return the
ReflectionClass instance for the loaded class. I think the current
interface is to restrictive in this case. As compromise it would be
possible to define a SplClassAutoloader interface too. This interface
extends the SplClassLoader interface and defines the methods register
and unregister.interface SplClassAutoloader extends SplClassLoader {
public function register($prepend = false); public function unregister();}
As a side note, the two interfaces doesn't violate the Single
responsibility principle.I know the reference implementation is named as SplClassLoader but
this should be renamed into SplDefaultAutoloader or SplPsrAutoloader
if implements the SplClassAutoloader or as SplPsrClassloader or
SplDefaultClassloader if implements the SplClassLoader interface.
Why not \Psr\Loader\Default? (I'm not trolling).
- The function
spl_autoload_register()should accept all
SplClassLoader implementations.I know it's already possible with the following syntax:
$classLoader = new MyCustomClassLoader();
spl_autoload_register(array($classLoader, 'load'));But the following syntax seems more consistent to me:
$classLoader = new MyCustomClassLoader();
spl_autoload_register($classLoader);
Yes, that will be a good update I think! It could be a parallel work of
SplClassLoader RFC, no? Quite easy I think.
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at LIFC/DISC (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
Hi guys,
I am removing my vote due to a particularly annoying aspect of this
whole RFC/voting structure: the RFC is still in flux!
How on earth are we supposed to be able to vote yay/nay on something
if that something keeps changing, or is very poorly defined? I request
that the RFC itself be discussed further, decisions made on what is
actually to be proposed (the idea of an SplClassLoader in
core/pecl/github/magicyfairyland, or a specific implementation against
SPL, or some interface(s), or some PHP implementation [why is that
even in the RFC?], or ...?), writing the outcome of those decisions
down, then formulating a vote (or selection of votes) only after all
of that.
If the RFC is already considered finalised, please stop changing it.
If the vote is intended as a yes/no to something that's still under
discussion or subject to change, clearly state that in the RFC/vote
page. If the RFC is not finished and voting on it makes little sense,
please remove the poll.
Frustratingly,
Peter
Hi,
I'm fine with the most of the implementation. But I have some suggestions to
optimize it.
- The interface should be named SplClassLoader and the register and
unregister methods should be removed.It should be possible to define class loader implementations without
registering them as autoloader because autoloading isn't the only way to
load classes. A class loader could as example return the ReflectionClass
instance for the loaded class. I think the current interface is to
restrictive in this case. As compromise it would be possible to define a
SplClassAutoloader interface too. This interface extends the SplClassLoader
interface and defines the methods register and unregister.interface SplClassAutoloader extends SplClassLoader {
public function register($prepend = false);
public function unregister();
}As a side note, the two interfaces doesn't violate the Single responsibility
principle.I know the reference implementation is named as SplClassLoader but this
should be renamed into SplDefaultAutoloader or SplPsrAutoloader if
implements the SplClassAutoloader or as SplPsrClassloader or
SplDefaultClassloader if implements the SplClassLoader interface.
- The function
spl_autoload_register()should accept all SplClassLoader
implementations.I know it's already possible with the following syntax:
$classLoader = new MyCustomClassLoader();
spl_autoload_register(array($classLoader, 'load'));But the following syntax seems more consistent to me:
$classLoader = new MyCustomClassLoader();
spl_autoload_register($classLoader);Christian
Am 09.11.2011 02:23, schrieb guilhermeblanco@gmail.com:
For all those interested, I implemented what I referred as item 2:
<quote> After some thought it makes sense, but only if interface then defines the setMode prototype. The background for this is supported if the user decides to enhance the base class to support caching, requiring the injection of the Cache layer in constructor. If it's part of the interface, it cannot be changed. </quote>RFC is now updated covering this. If you have more questions or
suggestions, feel free to tell me.On Tue, Nov 8, 2011 at 3:55 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Hi Nikita,
Thanks.
It's your option and I won't fight. But it seems my proposal is not yet
100%.
Some things I have either identified or people have reported.1- Remove ->register() and ->unregister(), and make the
spl_autoload_register to support SplClassLoader.I'm really +0 on this one.
But since the proposal covers an OO approach for autoload, it makes
sense the registering is pat of the available API, not in procedural
land.2- Remove constructor prototype in interface
After some thought it makes sense, but only if interface then defines
the setMode prototype.
The background for this is supported if the user decides to enhance
the base class to support caching, requiring the injection of the
Cache layer in constructor. If it's part of the interface, it cannot
be changed.
I took this example after looking at Symfony's
ApcUniversalClassLoader:What do you think about these 2 points?
Even if you're against the proposal, for sure you can still help to
make it consistent.Cheers,
On Tue, Nov 8, 2011 at 3:39 PM, Nikita Popov nikita.ppv@googlemail.com
wrote:On Tue, Nov 8, 2011 at 6:28 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Because there's no need to bring to C a single foreach.
Also, if you re-read the RFC, you'll see that SplClassLoader is
extendable for personalized developer needs, such as an addAll or an
APC lookup.After your changes the RFC looks much more decent. I am still opposed
to the idea of this going into core (mainly because there is no
necessity), but now the implementation is somewhat more useful.Nikita
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
I am removing my vote due to a particularly annoying aspect of this
whole RFC/voting structure: the RFC is still in flux!
This is one of the reasons why I've voted -1: there's no way an RFC
should be changing this much (or at all, really) while voting is open.
For the record, the other reasons I voted -1 were:
-
I think it's too late in PHP 5.4's release cycle to be proposing
anything for 5.4. -
I've yet to be convinced this needs to be done in SPL. Or in C at
all, really, if there are already perfectly good PHP implementations
of the standard. Let the community decide what they want to use.
Thanks,
Adam
Hi!
- I think it's too late in PHP 5.4's release cycle to be proposing
anything for 5.4.
Not talking about the merits of the loader, if it comes into 5.4, that
won't be 5.4.0. Unless we discover some very bad problem, 5.4 is going
into RC tomorrow, which means I will be extremely reluctant to change
anything that is not a bug.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Tue, Nov 8, 2011 at 6:55 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
Hi Nikita,
Thanks.
It's your option and I won't fight. But it seems my proposal is not yet
100%.
Some things I have either identified or people have reported.1- Remove ->register() and ->unregister(), and make the
spl_autoload_register to support SplClassLoader.I'm really +0 on this one.
But since the proposal covers an OO approach for autoload, it makes
sense the registering is pat of the available API, not in procedural
land.
+1 on remove, don't duplicate things already part of php.
While on duplication, why complicate things by having custom
$includePathLookup support?
This is already handled by php isn't it?
2- Remove constructor prototype in interface
After some thought it makes sense, but only if interface then defines
the setMode prototype.
The background for this is supported if the user decides to enhance
the base class to support caching, requiring the injection of the
Cache layer in constructor. If it's part of the interface, it cannot
be changed.
I took this example after looking at Symfony's
ApcUniversalClassLoader:
+1 on removing constructor from interface.
But imo SplClassLoader should have a constructor where you can optionally
provide a hash of namespace and path, so you can do:
spl_autoload_register( new SplClassLoader( array(
'ns' => 'path/',
'ns2' => 'path2/'
) ) );
(assuming spl_autoload_register gets native support for SplAutoloader,
otherwise it it will of course have to be provided as a callback)
On Tue, Nov 8, 2011 at 6:28 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Because there's no need to bring to C a single foreach.
Also, if you re-read the RFC, you'll see that SplClassLoader is
extendable for personalized developer needs, such as an addAll or an
APC lookup.
After your changes the RFC looks much more decent. I am still opposed
to the idea of this going into core (mainly because there is no
necessity), but now the implementation is somewhat more useful.
A necessity is the speed. Metagoto was cited in the RFC but its
benchmark was not cited. Here is it:
http://blog.runpac.com/post/splclassloader-php-extension-benchmarks.
It's interesting (/ping guilhermeblanco, please can you add this to the
RFC?)
I'm just proposing a new resource but not taking a position (I didn't
vote yet).
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at LIFC/DISC (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
2011/11/8 guilhermeblanco@gmail.com guilhermeblanco@gmail.com:
Ok... I promised to complete the RFC and here I am.
I wrapped the entire idea, PHP implementation of what I'm proposing all in RFC.
If you're interested, feel free to review the document, highlight if I
missed something and update/add your votes.
Varying degrees of complete. There was another discussion about it here the
other week. Some technical issues were mentioned.
Not sure everyone has conceptualized the implementation consequences yet.
But I find it very telling that it goes completely unnoted in the proposal doc.
Again.
(The manual page, btw, is still to be written. ;) So don't assume it's
completely
under the rug. If not in time for the voting, I think it might be fair
to users at least
to cursorily document how this autoloader scheme favours legacy frameworks
with the PEAR1 filenaming tradition.)
If you should remember and might want to add some details of the preceded
comments (rfc? right?), this URL would also work:
http://Wiki.php.net/RFC/SplClassLoader
But I guess that irony will be lost on some. :]
I updated the RFC a few hours ago based on a lengthy discussion in> php-standards.
Point of order. Discussions on RFCs are supposed to happen on the
internals list. That's the point of an open RFC process, so that the
discussion and justification can be made public for all to see. The
RFCs under discussion should not be changed during this time with the
exception of changes requested in the formal discussion.
If the RFC was changing during the discussion phase due to closed-door
discussions, then I think that it voids the discussion phase entirely.
Why am I so adamant against this RFC? Simple: the implementation
won't do what people have been promised. There are dozens of
different PSR-0 implementations out there (Heck, Symfony has 5
of them). Why are we trying to lock the core down to the most
limiting version? And at that point, why isn't the
http://pecl.php.net/package/automap Automap extension being considered
for inclusion instead/in addition? Rather than trying to find the
right solution for the core, the focus has been on a solution.
That's the wrong approach in my opinion and I fear that projects and
users will suffer in the long run. And that doesn't even hint at the
deficiencies that others and myself have pointed out with PSR-0
itself.
I don't want to beat a dead horse here, but I still think that it's
important to solidify the RFC prior to the voting phase can
legitimately happen. Otherwise people are voting on a moving target
(which isn't reasonable IMHO). I won't bring it up again, but I feel
it's important to assert this officially...
Anthony
On Mon, Nov 7, 2011 at 12:41 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:
Hi Ivan,
I updated the RFC a few hours ago based on a lengthy discussion in
php-standards.
It seems after these 2 years of PSR-0, all the rules are kept, but
some changes were made to the original code (the one in RFC) to
enhance the support. They are:
- Multiple paths per namespace
- Silent mode
The first one seems very useful in a component based library, while
the second is intended to not explode the class required if you have
multiple instances of ClassLoader.
I added quickly the methods ->registerNamespace() and
->registerPrefix() to RFC, but I still require to update the
SplClassLoader PHP based version.By now, you can either look at Symfony 2, Doctrine 2 or Zend Framework
2 to see the implementation details.Cheers,
On Mon, Nov 7, 2011 at 3:36 PM, Ivan Enderlin @ Hoa
ivan.enderlin@hoa-project.net wrote:Hey everyone,
Hi David,
After lengthy discussions and various opinion, we believe this issue
has been discussed at length and the PSR-0 has had this standard
effective for the past 1.5 year.The SplClassLoader RFC has moved to "voting" stage. Please cast your
votes at https://wiki.php.net/rfc/splclassloader/voteThank you very much for all the interest showed so far,
I'm very interesting by SplClassLoader but the RFC is not consistent. You
give an example that actually does not follow the proposed implementation
(e.g. the registerNamespace() and registerPrefix() methods are not present
in the proposed implementation).I have a solution in Hoa (a set of libraries, please, see my signature) for
supporting multiple paths per namespace. How can I contribute knowing that
Hoa's implement follows the RFC (since it's beginning).Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/PhD. student at LIFC/DISC (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/Member of HTML and WebApps Working Group of W3C
http://w3.org/--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil