Re: PEAR2 standards, we would like to know what you think
| From: | Pádraic Brady | 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