Re: Re: new template engine

"Alan T. Miller" wrote: > > Thomas, > > > IMHO the idea of PEAR is quite clear: "a set of highly reusable > > components that meet certain requirements of coding standars, > > documentation style, error reporting and quality". If Pear starts to > > accept everything, Pear will become something like hotscripts and > > believe me this will kill Pear. > > I never implied the idea would be to "accept everything." Standards would > obviously be applied to the process to make sure quality was maintained. > What I suggested was that those components that meet PEAR'S standards, > should be considered and allowed in if they do (or at least considered on a > case per case basis). The worst thing that would happen is someone has more > choices when they use PEAR... something many would appreciate and I think > would not hurt PEAR, and especially would not Kill PEAR. I surely do not see > how doing so goes against the definition / mission you give of "a set of > highly reusable components that meet certain requirements of coding > standars, documentation style, error reporting and quality". If doing so > would go against that definition please explain why. There is one thing: having too many alternatives makes it easier to re-use a certain type of functionality. Say I want to make The Ultimate HTML Form Class[tm], and I want to make it easy to bind a form to a row in a database table. Which database abstraction layer should I support? If I support only PEAR DB, the people using other classes that want PHPLIB's DB_Sql can't use it, and vice versa. Ditto for authentication layers, session stuff, caches and all kinds of places you want to have database connectivity. You risk ending up with a bunch of square pegs and only round holes. And that is contrary to PEAR's mission: to create a set of _highly reusable_ components. So it's obvious to me that there are some "domains" of functionality where multiple choices may become a real pain in the hind quarters for PEAR users, while other "domains" where it's great. You could visualize it like this: make a mesh/graph/web with directed links between (PEAR) packages. If one package points to another, it uses code from that package somehow. Do this for all of PEAR, and count the number of "incoming arrows" in each package. The packages with the most incoming arrows are the ones where you want to standardize a bit harder. This doesn't mean cutting off the hands of people contributing new packages, it means we have to try making them help evolve existing code in a compatible way rather than adding a new incompatible interface. If there is absolutely no way it can be done, fine, but I refuse to believe that until I see it. :-) [..snip..] > > Perhaps some parts not yet very > > "user-friendly" but this subject is changing step by step. And of course > > if you want to see that happen more quickly you only need to join Pear > > :) > > I am more than willing to contribute in any way I can. I joined this list at > Stig's request after meeting him at ApacheCon 2000 and seeking to volunteer > to help with the web site. For the most part I am a web developer and would > like to contribute my efforts in helping to build the web site and with > documentation and or anything else I can contribute. Any ideas... let me > know. You meant ApacheCon 2001 of course. :-) - Stig (now officially typing with both hands again)