Re: Multiple classes that do the same [extends 'We need another Auth']
| From: | Stig S. Bakken | Date: | Wed, 12 Jun 2002 00:45:41 +0000 |
| Subject: | Re: Multiple classes that do the same [extends 'We need another Auth'] | ||
| References: | 1 2 3 4 5 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-6939@lists.php.net to get a copy of this message | ||
On Mon, 2002-06-10 at 21:01, Wolfram Kriesing wrote:
> i hope there will never be more than one package that does one thing.
> i think that a long time ago it was (commonly) agreed that PEAR was
> going to be a pool of classes which provides _one_ solution for each
> problem and not many as CPAN does.
> May be we should ask Stig, if that wasnt one of his goals for PEAR?
> i am sure having just one of each will improve easy-use and better
> overview.
> i think the Auth-discussion that has come up is giving even more
> reason to 'design' stuff before implementing and putting it in PEAR (i
> am not saying Auth was not 'designed' properly, i just mean that the
> discussion shows that some kind of 'design-process' is needed).
> I am not (exactly) going to suggest a process as Java has the 'Java
> Specification Process' or what it is called. but agreeing on the
> functionality and the way something gets implemented might be a good
> thing when starting to work on something.
> i am just saying that because i would really love to see PEAR becoming
> a project where people will say: 'look at PEAR that is nice
> code/design/work etc.'
> BTW i like the coding standards too, but i dont want to start a
> discussion on that now.
>
> thanks to everyone who makes life easier by providing PEAR-code, it
> really made my work much more efficient
>
> just my 2 cent
I started out with a goal of not having duplicate functionality at all,
but quickly realized that this was neither realistic or really desirable
as an absolute requirement.
In practice, for some classes having multiple implementations is fine,
but for others it's not. Having more than one database abstraction
layer is no good, since it would hinder reuse in other classes a lot.
Having multiple template systems seems to be inevitable because people
feel so strongly about the one they prefer. ;-)
- Stig
--
Stig Sæther Bakken, Fast Search & Transfer ASA, Trondheim, Norway
http://pear.php.net/wishlist.php/ssb