On Saturday, April 5, 2003, at 11:16 PM, Kip Hampton wrote: <snip>
1) It's inefficient - or at the least it makes it very difficult to optimize data handling.Explain. How is using a mechanism that's already there less efficient than re-inventing it?
Because you have to make assumption at various points as to how data will be represented, and you need to check for various different types of data. As an example, every single language processor has to check for dom_tree in pnotes, then xml_string in pnotes (which it'll then reparse) and then fall back to using the provider. By standardizing the interface for obtaining data (to subclasses of Provider) methods are available to give the data in any form the processor wants, without it having to do the search itself.
As I also said, it makes it difficult to optimize because your limited to doing everything via scalars in dom_tree or xml_string (which are of specific types). But by standardizing on an object interface we can look at extending it or changing the internals to optimize how the data is actually represented internally. Examples might be optimizing for space by using some sort of data minimization or compression, or optimizing for speed by keeping various versions (eg. strings, sax events, etc) that can be provided. You might not consider these great ideas for optimizations, but that isn't a great reason to limit the flexibility.
As for re-inventing the interface - AxKit already reinvents the entire process anyway. It has to stuff around reblessing the Apache object to an Akit::Apache object (and blessing it back at various points), and the pnotes method is captured and redirected to use a localized hash internally to AxKit.
2) It makes the data flow within the system unclear. It's effectively like using a global variable in the code to pass data around in - and we all know global variables are generally bad >> design.
Apples and oranges. The use of pnotes in AxKit provides a predictable place to for *all* AxKit classes to access/set metadata-- that's not the same thing as having a global var. And anyway, how is re-inventing pnotes' functionality (e.g. "a place to store metadata so all classes can access it") within AxKit any less "global"?
First up, it's not predictable as I've already said. There's already several different ways the data or metadata is managed (pnotes, content_type, return codes, etc) and the use isn't predictable - it could be in dom_tree, xml_string, the provider, etc.
And since everywhere in the code tries to look for data in $r->pnotes('xml_string') or $r->pnotes('dom_tree'), where $r has to be the same $r, then I think this is pretty analogous to a global variable.
My patches don't re-invent pnotes functionality - they obsolete them. Data (and metadata) is now passed as arguments to the handler method, and retrieved via the return values. Since this is entirely encapsulated within the function call/return I think thats certainly not global.
3) It ties the core of AxKit to the Apache object interface and implementation. If it was ever desired to use AxKit separate from Apache (eg. via CGI or something) then it makes the implementation quite complex as you'd have to reimplement the Apache object completely.
"What if" cases carry no weight. IMO, the individual silly enough to run a heavy framework like AxKit via CGI needs to take careful aim at their foot, and we would be wrong to help them. If you want to provide a fake $r for use in CGI, be my guest, but I don't think AxKit itself should be slanted in that direction.
'What if' does carry some weight when it's not impractical to implement. Someone might have a very good reason for wanting to use AxKit outside Apache, so why should we limit that usage unnecessarily - especially since it doesn't make things harder (I would argue it's better anyway). Another "what if" might be the Apache interface changing (Apache2?). If there are significant changes then that means AxKit has to change significantly to match. Or "what if" someone wanted to use AxKit with a webserver other than Apache. At the moment....impossible. But with the changes I've suggested it would become a lot easier.
> I'm not simply resisting you here, Chris. There are some good ideas in the patches that you proposed, but part of what makes AxKit robust, flexible and able to perform well despite the heavy requirements of XML-based Web publishing is the fact that it takes advantage of what's already there in Apache and mod_perl. So, every little bit is not encapsulated behind some AxKit-specific interface-- so what? Sometimes the more pragmatic approach of simply using what's already there (and has proven to work) is greatly to be preferred over any subjective notions of OO-cleanliness.
I'm not suggesting that using what's already there is a bad idea. But really, what's already there is being used in a way that it wasn't intended for. The simple fact that AxKit has to rebless the Apache object and proxy quite a number of the methods clearly shows that. To be honest, I'd be far more worried about the stability of doing things like that than I would be about implementing a little bit of internal data passing and handling code. As for flexibility, at the software architectural level it is only obtained by considering the "what if's" and ensuring the code can cope with them with only superficial changes.
None of the suggestions or changes I've made are rooted in the idea of OO cleanliness. OO is a tool that allows for flexibility, to be used where appropriate. I used it a lot in my patches because it made sense for what I was trying to achieve - not because I am an OO bigot or something. I guess the ability to see what structures are good at an architectural level is something that only comes with extensive software engineering experience - something which I have (I've been tasked with refactoring and guiding development of numerous very large projects) and trust in myself.
Regards, Chris
PS. Shouldn't we drop some of the CC's if we continue the discussion?
PGP.sig
Description: This is a digitally signed message part
