Re: PEAR2 standards: anything good at all?

Hi, I think it would be beneficial to put a summary of the current possible changes to the RFC somewhere (or an updated draft). I haven't had time to follow the discussion fully so I at least have gotten a little confused as to how the RFC now relates to the mentioned problems its initial reading raised. >__autoload() is not slower .. if you are not using a bytecode cache you >will end up including a lot of files you never need if you rely on >require_onc'ing all files containing classes that the code _could_ load. __autoload() is an efficient solution for shared hosts - but you can't rely on it being defined as __autoload() since that's going to be the first thing an application using autoloading will implement (like most of mine ;)). An SPL registered alternative might work - I do think this will be hugely confusing to any current user having problems setting an include_path (and probably even above that level since it's a rarely used function) so it somewhat trades one support issue for another which is potentially more complex. Also this adds multiple autoload implementations - you have to wonder which is more efficient, a few loner require_once calls or X number of autoload checks. To top it off, __autoload() and its ilk make for some messy error handling internally. On unzip-and-go, I still don't get this. I have to assume this only impacts packages with fixed paths set at install time? Which are few in number as far as I know. It doesn't seem to offer much benefit to packages as a whole collective since, of those I use, all are pretty easy to move around and include where I want. > * slow require_once in APC is a problem of APC, not PEAR. APC > developers are aware of it and are solving it, so sometime our > optimizations may become counter-productive. Is it slower under APC? I figured it cached the required file regardless of the inclusion mechanism. The main inefficiency was in sorting out relative paths passed to require_once, something PHP 5.2 was to address with a realpath cache. Not an internals person so maybe someone can clarify this. It was a lot slower, from what I remember, up to a year ago when APC was being distributed with a specific bug later resolved. Its seems APC + require_once + __autoload() keeps getting changed between performing well and performing badly every few days. It's been months since PHP 5.2 was released - it can't be that hard to figure out which one is right at this point in time. Did either of the two benchmarks which seem to disagree on results test this? >* Base exception class - Yay consistency, notice a theme here yet? >Make it easy to figure out where this exception came from. Line numbers and file names generally do that. I think all PEAR_Exception really does is make for nice Exceptions when output. Which is...well...nice, I suppose. I don't see it offering anything adding to consistency per se. Not that I don't appreciate a nice stack trace :). Reading back, this is a huge thread with lots of repetition.. I think the original RFC's goals were unclear to start with and really need explanation before introducing the proposed coding changes. A read though suggests they are making a *lot* more sense now than the thread started. Regards, Paddy Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com ----- Original Message ---- From: Lukas Kahwe Smith <mls@pooteeweet.org> To: Travis Swicegood <development@domain51.com> Cc: Alexey Borzov <borz_off@cs.msu.su>; pear-dev@lists..php.net Sent: Monday, July 16, 2007 3:11:48 PM Subject: Re: [PEAR-DEV] PEAR2 standards: anything good at all? Travis Swicegood wrote: > Lukas Kahwe Smith wrote: >> The difference is that users in this case will be "forced" to rely on >> PHP native functionality and that they can expect a clear error >> message. So I am not so worried, but of course we will still see our >> share of "__autoload() wtf" support requests. > > I think you just hit on something there, Lukas. __autoload and > include_path are both features that aren't going to be immediately > apparent to the new user that this is supposed to help. You're trading > one support/bug request for another... Just that one of them provides some added benefits while the other doesnt. > In any event, I see either of these proposed methods as a trade-off. > __autoload() is going to be slow, allfiles is going to gobble up __autoload() is not slower .. if you are not using a bytecode cache you will end up including a lot of files you never need if you rely on require_onc'ing all files containing classes that the code _could_ load. allfiles will provide (or a custom variant as per the user) the potential for noticeable speed gains for people that have already done all the standard performance enhancement steps. > memory. From the discussion that I've seen and participated in, we have > two camps here that are equally intractable. I seriously doubt any > further discussion is going to sway any minds, so I would be for moving > this to a vote (or whatever would start its end of life cycle) so the > standard can be adopted and/or rejected and people can likewise move on > to to the important task of following or ignoring it... ;-) I simply fail to see the disadvantages from this proposal, aside from that it requires a change in policy. Giving the fact that _all_ our current users stand to gain and that we also provide solutions for people we currently left in the dust, I am having a hard time to see the migration effort as a big issue .. especially since this is for a new major version of PEAR. regards, Lukas -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php ____________________________________________________________________________________ Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/