Re: PEAR2 standards, we would like to know what you think

From: Date: Mon, 09 Jul 2007 09:13:30 +0000
Subject: Re: PEAR2 standards, we would like to know what you think
Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-47284@lists.php.net to get a copy of this message
Hi, The new kid on the block is a little confused about why require_once is disallowed and class_exists() is enforced. The first is almost inevitable, the second undependable. For example, using class_exists() with the TRUE parameter means it will call __autoload(). Presumably, the user defines __autoload() at the application level. So how can one honestly call an unknown function, with an unknown implementation, and...hope for the best? This use of __autoload() is too dodgy - I know that I have application leveraging off PEAR which define __autoload() for locating my Model classes. Their naming convention is different from the PEAR standard (no prefixing). Calling my __autoload() would start running file_exists()/file_readable()/other checks for no good reason. Also, __autoload() does not make full use of an opcode cache. For rarely seen Exception classes that's usually okay - but not for entire packages. XDebug will not like... It shall moan. It shall groan. Secondly, eliminating require_once() seems to cater to the allfiles.php kludge. Since __autoload() falls flat - I can only assume allfiles is the way forward. But this too has a small problem - it's only a benefit to a platform with an opcode cache. What if I have no opcode cache? What if I use a shared host because paying $19.99 per month for my personal applications is sufficient for a few hundred visitors? Now I'm facing a memory spike, complaints from XDebug when profiling, reduced requests per second, and increased filesystem operations. That $29.99 plan starts looking more interesting - or else removing PEAR2 from the equation will. There's a reason why alternative libraries like Template Lite and ADOdb Lite are so popular these days. The rest of the RFC seems fine - the CS restrictions on how files are loaded however isn't making much sense to me. I just can't imagine loading up a large package in it's entirety just to use a handful of classes specific to my needs, or allowing PEAR to access my __autoload() function which differs depending on the application. Best regards, Pádraic Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com ----- Original Message ---- From: Alexey Borzov <borz_off@cs.msu.su> To: Arnaud Limbourg <arnaud@limbourg.com> Cc: PEAR developer mailinglist <pear-dev@lists.php.net> Sent: Monday, July 9, 2007 8:35:35 AM Subject: Re: [PEAR-DEV] PEAR2 standards, we would like to know what you think Hi, Arnaud Limbourg wrote: > Please read the following document and post your comments on the wiki > using the discussion page. Comments are opened for a period of two weeks. > > It is very important that you comment as these standards will define PEAR2. > > RFC at: > http://wiki.pear.php.net/index.php/PEAR2_Standards The wiki doesn't let me in with PEAR username / password, so I won't bother commenting there. There are 2 major problems with this document that should be fixed before soliciting comments: 1) There are two completely independent parts in the document, first dealing with coding standards and the second with collectives. The document should be split and each part discussed separately. 2) The part dealing with coding standards inspires a major "WTF?" feeling. I suspect that's mainly because we see a hypothetic solution to some problem, but not the problem itself, so I suggest adding a couple paragraphs on what you are trying to solve there. -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

« previous php.pear.dev (#47284) next »