On Mon, Jun 27, 2011 at 12:19, rod wrote:
> Quick question: is there any planned inclusion in PHP for an SplClassLoader?
>
What would that class do that the spl_autoload*() functions don't?
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.ne
I suppose what he means is a classloader *implementation*.
Something along the lines of:
function($class) {
return str_replace('\\', DIRECTORY_SEPARATOR, $class) . '.php';
}
2011/6/27 Hannes Magnusson
> On Mon, Jun 27, 2011 at 12:19, rod wrote:
> > Quick question: is there any planned incl
Yes sorry this is what I mean, a PSR0 compliant autoloader class built
in as standard.
$loader = new SplClassLoader();
$loader->register( '/path/to/my/library' );
etc...
On 27 June 2011 11:57, Dennis Haarbrink wrote:
> I suppose what he means is a classloader *implementation*.
> Something along
Hannes,
There's a RFC covering this. There's a patch also.
https://wiki.php.net/rfc/splclassloader
[]s,
On Mon, Jun 27, 2011 at 7:59 AM, rod wrote:
> Yes sorry this is what I mean, a PSR0 compliant autoloader class built
> in as standard.
>
> $loader = new SplClassLoader();
> $loader->register
>
> There's a RFC covering this. There's a patch also.
>
> https://wiki.php.net/rfc/splclassloader
This one seems to have fallen through the cracks?
I know this would benefit many of the frameworks that are out there and give
a speed bump to people utilizing them. Is this a possibility for 5.4?
Hi!
On 6/29/11 6:31 AM, Mike Willbanks wrote:
There's a RFC covering this. There's a patch also.
https://wiki.php.net/rfc/splclassloader
This one seems to have fallen through the cracks?
Well, nobody proposed it in time (especially not the RFC author :)
* The other implementation I coul
Hi internals,
It's been a while since Stas accepted that, but it seems the class
haven't been merged since then.
What's the status of this? Can I expect SplClassLoader in 5.4.0?
It seems it was approved, but wasn't merged and thread was lost in space. =(
There's an RFC for it: https://wiki.php.n
On Mon, Oct 24, 2011 at 3:47 PM, guilhermebla...@gmail.com
wrote:
> Hi internals,
>
> It's been a while since Stas accepted that, but it seems the class
> haven't been merged since then.
> What's the status of this? Can I expect SplClassLoader in 5.4.0?
>
> It seems it was approved, but wasn't mer
On 24 October 2011 16:53, Paul Dragoonis wrote:
> On Mon, Oct 24, 2011 at 3:47 PM, guilhermebla...@gmail.com
> wrote:
>> Hi internals,
>>
>> It's been a while since Stas accepted that, but it seems the class
>> haven't been merged since then.
>> What's the status of this? Can I expect SplClassLoa
On Mon, Oct 24, 2011 at 3:57 PM, David Coallier wrote:
> On 24 October 2011 16:53, Paul Dragoonis wrote:
>> On Mon, Oct 24, 2011 at 3:47 PM, guilhermebla...@gmail.com
>> wrote:
>>> Hi internals,
>>>
>>> It's been a while since Stas accepted that, but it seems the class
>>> haven't been merged si
On 24 October 2011 15:57, David Coallier wrote:
> On 24 October 2011 16:53, Paul Dragoonis wrote:
>> On Mon, Oct 24, 2011 at 3:47 PM, guilhermebla...@gmail.com
>> wrote:
>>> Hi internals,
>>>
>>> It's been a while since Stas accepted that, but it seems the class
>>> haven't been merged since the
hi,
I'd to be in favor to include it. However I would like to hear more
from the people behind PSR-0 to be sure that it is actually what is
needed and to complete the RFC (it is rather missing real info,
examples and tests).
Please also update the patch and attach it to the RFC.
Cheers,
On Mon,
I've been following this but not on the internal portions of PSR-0...
Why it is needed:
Currently all of the implementations on the autoloading side is pushed in
through a custom class or function inside of spl_autoload whereas the
registered autoloading takes place. Currently each framework that
Hi!
On 10/24/11 9:45 AM, Mike Willbanks wrote:
By standardizing this inside of an extension gains us 2 very major features
(IMO):
But we already have the extension, don't we?
From the RFC prospective it does seem like many things are missing:
1. Examples
* The easiest example being that of
On Mon, Oct 24, 2011 at 10:20 AM, Peter Cowburn wrote:
> On 24 October 2011 15:57, David Coallier wrote:
> > On 24 October 2011 16:53, Paul Dragoonis wrote:
> >> On Mon, Oct 24, 2011 at 3:47 PM, guilhermebla...@gmail.com
> >> wrote:
> >>> Hi internals,
> >>>
> >>> It's been a while since Stas a
>
>>
>> What are peoples' thoughts on the name of the class? The word "auto"
>> fits best with all that has come before, yet the proposal here uses
>> "class": what about SplAutoloader? With the introduction of this new
>> class, whatever the name, what happens to __autoload() and
>> spl_autoload_
>
> I've started toying around with adjusting the patch. A bit of rewrite
> is required but I'm attempting to modify the patch to be included
> directly in SPL with the name SplClassLoader so that one can do:
>
> $cl = new \SplClassLoader(..., ...);
>
> Once the patch is adjusted to fit with SPL
hi,
Could you open a FR at bugs.php.net and attach the patch to it please?
Could be easier to track (and the # to the RFC too :)
On Mon, Oct 24, 2011 at 11:25 PM, David Coallier wrote:
>>
>> I've started toying around with adjusting the patch. A bit of rewrite
>> is required but I'm attempting
>
> Could you open a FR at bugs.php.net and attach the patch to it please?
> Could be easier to track (and the # to the RFC too :)
>
Yeah I'll do that once I have the tests adjusted and once I know the
patch actually works as expected.
--
David Coallier
--
PHP Internals - PHP Runtime Developme
Hi internals,
For all those interested, I have updated the RFC with better
explanation, included example implementation and also example usage.
If you have any other wishes, doubts, etc, feel free to ask on this
thread and I'll quickly answer here and also update the RFC
accordingly.
The url for
I think the following two requirements should be covered by configuration
aswell:
1. Have the autoloader be silent, i.e. doing a file_exists() check. API idea
$loader = new SplClassLoader(..., SplClassLoader::SILENT);
2. Have a ASSERT_CLASS_EXISTS mode, i.e. after the require an
"if(!class_exists(
On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Hi internals,
>
> For all those interested, I have updated the RFC with better
> explanation, included example implementation and also example usage.
> If you have any other wishes, doubts, etc, feel f
On Tue, Oct 25, 2011 at 12:49 PM, Benjamin Eberlei wrote:
> I think the following two requirements should be covered by configuration
> aswell:
>
> 1. Have the autoloader be silent, i.e. doing a file_exists() check. API
> idea
> $loader = new SplClassLoader(..., SplClassLoader::SILENT);
> 2. Have
On 2011-10-26, André Rømcke wrote:
> --bcaec5216025460b0e04b031fc2a
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
> > For all those interested, I have up
2011/10/26 André Rømcke :
> On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
>> Hi internals,
>>
>> For all those interested, I have updated the RFC with better
>> explanation, included example implementation and also example usage.
>> If you have a
On Thu, Oct 27, 2011 at 4:30 AM, Laruence wrote:
> 2011/10/26 André Rømcke :
> > On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com <
> > guilhermebla...@gmail.com> wrote:
> >
> >> Hi internals,
> >>
> >> For all those interested, I have updated the RFC with better
> >> explanation, inclu
Can I make a point here.
Why the heck are we caring about the performance of the autoloader at
all here? The filesystem operations necessary (at least the stat()
call) will greatly dominate any string function. And considering that
even the biggest framework only has perhaps a few hundred classe
I couldn't agree more with Anthony. In conjunction with that, I would continue
to question the full benefit to the community. How many existing code
bases/frameworks out there would implement this in favor of their existing
solution?
Will
On Nov 3, 2011, at 11:19 AM, Anthony Ferrara wrote:
On Thu, Nov 3, 2011 at 4:19 PM, Anthony Ferrara wrote:
> Can I make a point here.
>
> Why the heck are we caring about the performance of the autoloader at
> all here? The filesystem operations necessary (at least the stat()
> call) will greatly dominate any string function. And considering tha
On Thu, Nov 3, 2011 at 3:19 PM, Anthony Ferrara wrote:
> Can I make a point here.
>
> Why the heck are we caring about the performance of the autoloader at
> all here? The filesystem operations necessary (at least the stat()
> call) will greatly dominate any string function. And considering that
Paul,
I wasn't saying whether it should be included or not. I was saying
that performance should not be a justification for it being included.
It may be a benefit, but it's a very small side benefit as opposed to
a primary one.
Additionally, I wholeheartedly disagree with one of your points ther
On Thu Nov 3 11:19 AM, Anthony Ferrara wrote:
>
> But that's besides the point. I just want to emphasize the point that
> performance should not be a criteria for justifying it going into the
> core...
>
There also seems to be the perception among some php devs that autoloading
is now the pre
Wouldn't you consider spl_autoload_register an interoperability solution? Only
your defined autoloading function would then need to know how your file system
is structured, there'd be no need for include_path declarations and you
wouldn't have to explicitly declare paths for each class.
On Nov
2011/6/27 guilhermebla...@gmail.com :
> Hannes,
>
> There's a RFC covering this. There's a patch also.
>
> https://wiki.php.net/rfc/splclassloader
I do have a few remarks:
1. That is not a *class* loader, that is a loader (also for
interfaces), hence my suggestion s/SplClassLoader/SplLoader/
2. PS
On Thu, Nov 3, 2011 at 7:30 PM, Anthony Ferrara wrote:
> Paul,
>
> I wasn't saying whether it should be included or not. I was saying
> that performance should not be a justification for it being included.
> It may be a benefit, but it's a very small side benefit as opposed to
> a primary one.
>
On Fri, Nov 4, 2011 at 10:33 AM, André Rømcke wrote:
> On Thu, Nov 3, 2011 at 7:30 PM, Anthony Ferrara
> wrote:
>
> > Paul,
> >
> > I wasn't saying whether it should be included or not. I was saying
> > that performance should not be a justification for it being included.
> > It may be a benefi
On Thu Nov 3 03:06 PM, Will Fitch wrote:
> Wouldn't you consider spl_autoload_register an interoperability
> solution? Only your defined autoloading function would then need to
> know how your file system is structured, there'd be no need for
> include_path declarations and you wouldn't have to
Jonathan,
> The problem with spl_autoload_register() is it isn't clear what the
> autoloading function is supposed to do if the class if not found.
Then that's a documentation problem. If you throw an exception in
yours, sure that's going to cause problems for anyone else. It's 100%
possible (a
On Nov 4, 2011, at 7:19 AM, Anthony Ferrara wrote:
> Jonathan,
>
>> The problem with spl_autoload_register() is it isn't clear what the
>> autoloading function is supposed to do if the class if not found.
>
> Then that's a documentation problem. If you throw an exception in
> yours, sure that's
Hi Tyra3l,
Comments are inline.
On Fri, Nov 4, 2011 at 8:35 AM, Ferenc Kovacs wrote:
> On Fri, Nov 4, 2011 at 10:33 AM, André Rømcke wrote:
>
>> On Thu, Nov 3, 2011 at 7:30 PM, Anthony Ferrara
>> wrote:
>>
>> > Paul,
>> >
>> > I wasn't saying whether it should be included or not. I was saying
Guilherme,
What's the status regarding the finalised PSR-0 implementation so we
can hand it over to DavidC to finish the C implementation and apply
this to 5.4 branch.
Cheers,
- Paul
On Fri, Nov 4, 2011 at 5:27 PM, guilhermebla...@gmail.com
wrote:
> Hi Tyra3l,
>
> Comments are inline.
>
> On Fr
Guilherme,
> The language is problematic, FIG/PSG are just trying to have zillions
> different implementations. Everyone would expect that language to set
> the standards, avoiding millions of weird pieces of code out there.
Actually, I'd argue that what you're saying here is the exact opposite
o
my comments are also inline
> > did you read the blogpost? most of your replies were cowered there.
> >
>
> Yes.
you mean you or André?
>
> "If you use lowerCamelCase on the class names or your namespace, it will
> > (/should) be exactly like on disk as well."
> >
>
> So as previously said,
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 names
I agree with Guilherme on this one. The voting objective seems very vague
currently.
On Mon, Nov 7, 2011 at 12:29 PM, guilhermebla...@gmail.com <
guilhermebla...@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
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
On Nov 7, 2011, at 10:50 AM, Anthony Ferrara wrote:
> 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 de
Am 07.11.2011 15:29, schrieb guilhermebla...@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
That would be even better
On Nov 7, 2011, at 10:59 AM, Sebastian Bergmann wrote:
> Am 07.11.2011 15:29, schrieb guilhermebla...@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.
>
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.
Y
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 ju
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
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
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
On 07/11/11 14:41, David Coallier 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 ca
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
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
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
> Si
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 distribute
On 07/11/11 18:41, guilhermebla...@gmail.com 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 s
Hi Anthony,
On Mon, Nov 7, 2011 at 3:43 PM, Anthony Ferrara wrote:
> 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 inclu
Hi Ivan,
On Mon, Nov 7, 2011 at 3:59 PM, Ivan Enderlin @ Hoa
wrote:
>
>
> On 07/11/11 18:41, guilhermebla...@gmail.com 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
Am 07.11.2011 18:36, schrieb guilhermebla...@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 BergmannCo-Founder and Principal Consultant
http://sebastian-
On 07/11/11 19:05, guilhermebla...@gmail.com wrote:
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 al
guilhermebla...@gmail.com wrote:
Hi Anthony,
On Mon, Nov 7, 2011 at 3:43 PM, Anthony Ferrara wrote:
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
im
guilhermebla...@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 Electro
On 07/11/11 19:17, Lester Caine wrote:
guilhermebla...@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 ...
+1. It would be great if PHP could host this mailing-list. It would be
an ac
On Mon, Nov 7, 2011 at 7:26 PM, Ivan Enderlin @ Hoa <
ivan.ender...@hoa-project.net> wrote:
>
>
> On 07/11/11 19:17, Lester Caine wrote:
>
>> guilhermebla...@gmail.com wrote:
>>
>>> To participate of php-standards group, feel free to join here:
>>> http://groups.google.com/**group/php-standards
> 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
On 11/07/2011 01:42 PM, Ferenc Kovacs wrote:
On Mon, Nov 7, 2011 at 7:26 PM, Ivan Enderlin @ Hoa<
ivan.ender...@hoa-project.net> wrote:
On 07/11/11 19:17, Lester Caine wrote:
guilhermebla...@gmail.com wrote:
To participate of php-standards group, feel free to join here:
http://groups.goo
On 11/07/2011 07:04 PM, Larry Garfield wrote:
> 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
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
On Tue, Nov 8, 2011 at 6:17 PM, guilhermebla...@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: al
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 3:25 PM, Nikita Popov wrote:
> On Tue, Nov 8, 2011 a
On Tue, Nov 8, 2011 at 6:28 PM, guilhermebla...@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 R
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 s
For all those interested, I implemented what I referred as item 2:
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
Cac
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, guilhermebla...@gmail.com
wrote:
> For all those interested, I implemented what I referred as
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
2011/11/8 guilhermebla...@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.
>
Hi,
I'm fine with the most of the implementation. But I have some
suggestions to optimize it.
1. 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
On 08/11/11 18:39, Nikita Popov wrote:
On Tue, Nov 8, 2011 at 6:28 PM, guilhermebla...@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
A
On 09/11/11 11:24, Christian Kaps wrote:
Hi,
Hi Christian :-),
I'm fine with the most of the implementation. But I have some
suggestions to optimize it.
1. The interface should be named SplClassLoader and the register and
unregister methods should be removed.
It should be possible to de
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 dis
On Wed, Nov 9, 2011 at 12:04 AM, Will Fitch wrote:
> ...
> 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
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
On 9 November 2011 22:44, Peter Cowburn wrote:
> 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 v
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 t
On Tue, Nov 8, 2011 at 6:55 PM, guilhermebla...@gmail.com <
guilhermebla...@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 ->
On Wed, Nov 9, 2011 at 2:03 PM, Anthony Ferrara wrote:
> 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
On Wed, Nov 9, 2011 at 5:16 PM, Rafael Dohms wrote:
> On Wed, Nov 9, 2011 at 2:03 PM, Anthony Ferrara wrote:
>
> 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
On Wed, Nov 9, 2011 at 8:49 PM, Anthony Ferrara wrote:
> On Wed, Nov 9, 2011 at 5:16 PM, Rafael Dohms
> wrote:
>> On Wed, Nov 9, 2011 at 2:03 PM, Anthony Ferrara wrote:
>
> I am not PSR compliant in either autoloader implementation or class
> implementation. The reason is that over time I have
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 w
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 woul
hi Stas,
On Thu, Nov 10, 2011 at 8:17 AM, Stas Malyshev 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. I
On Thu, Nov 10, 2011 at 10:36 AM, Pierre Joye wrote:
> hi Stas,
>
> On Thu, Nov 10, 2011 at 8:17 AM, Stas Malyshev
> 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 stabl
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 understa
2011/11/10 Pierre Joye :
> hi Stas,
>
> On Thu, Nov 10, 2011 at 8:17 AM, Stas Malyshev 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 abou
On Thu, Nov 10, 2011 at 11:00 AM, Stas Malyshev wrote:
> 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
On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT
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
>
1 - 100 of 116 matches
Mail list logo