Re: Package Proposal: XML_SaxFilters
| From: | Alan Knowles | Date: | Tue, 24 Jun 2003 23:49:11 +0000 |
| Subject: | Re: Package Proposal: XML_SaxFilters | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-17685@lists.php.net to get a copy of this message | ||
Is it worth thinking of using the base class as a factory/Interface definition, in the same way that DB/Image_Transform work.
Regards
Alan
Harry Fuecks wrote:
Hi Alan, Thanks again (appreciate sound advince from HTMLSax as well) - I tend to try for "perfect abstraction" (probably badly) first then get good advice later for the real world. Hot off the press, have done my best to explain SAX filters in a "Rough Guide" which also gives general detail about the API as well. This is now up at; http://code.phppatterns.com/XML_SaxFilters/docs/SaxFiltersGuide.phps [Not in the package yet] Also the read me which has some more info is online at; http://code.phppatterns.com/XML_SaxFilters/docs/Readme.phps As to the interfaces, will remove the includes so they are never processed. Would like still to include them in the package so show up in the documentation though; think it's important particularily for the FilterInterface that people developing filters remember to include those methods (or their filter will "break"). The AbstractParser could be merged with each of the "concrete" parsers I guess, though would prefer not to as they do use the methods there. Think AbstractFilter is a "must" though but perhaps some of the methods could be removed. Hopefully you have time to read the guide above where I've done my best to explain them - two in particular are "short cuts" to help avoid having to call the methods of another object via a property. Anyway - hope the Guide helps some more people decide + or -. If I can do any more to explain to anyone just say the word. As Eliotte Rusty Harold said in her guide to Sax Filters in Java (see first post); "In all of XML, I have found nothing quite so hard to understand yet easy to do as writing SAX filters. For a long time, it felt like I had a mental block preventing me from grokking just how filters worked, and yet every time I wrote one it almost always worked on the first try. In fact, even when I was convinced that the code I had written could not possibly work, it did. I can’t decide whether this is an example of wonderful or awful API design." On Tue, 24 Jun 2003 17:40:40 +0800, Alan Knowles <alan@akbkhome.com> wrote:Started having a quick look through this, enough to comment roughly, although not enough to understand it's purpose fully.. One thing of note from a browse around, was that although Interfaces are in PHP5, and they are generally a good idea for programming consistancy, they should be very carefully used when it comes to a compile/execute languages, In the case of the use here: - are the interfaces too small to be of any value? - is the extra include worth the speed penalty? - do the interfaces actually make the code more difficult to read? From my brief look, it would have been clearer to just remove the interfaces, and alot of the inheritance, and the little code replication you ended up with would be worth it in terms of clarity.. Regards Alan