Re: New XSLT class for PEAR

You make great points. I have always dealt with stateful objects, since I only recently dropped php3 support in phpGroupWare and never used classname::funcname before two days ago. After pondering your points I have to agree. I think this class can be re-written to work stateless as the standard. There is one exception that Im not really certain about the innerworkings yet. the exception is the batch mode stuff it apparently does. This would seem to require the object to be stateful, but I dont think it would need to be the default behaviour. I am working on the modifications to the XSLT_Wrapper right now and will try and get something for you to all review by this evening. Dan Stuart Herbert wrote:

I'm not very comfortable with OO yet, could you explain what you mean ? Arnaud.

I'll have a go. Flames to /dev/null please ;-) A stateful object is basically an object with memory. An object where you get/set values that are stored within the object. This is fine (imho) when your object is encapsulating a piece of data - such as a string, a file, a XML document, and so on. Can't really have it any other way. On the other hand, another type of object is one that *does* something to datatypes. A XSLT Processor is an excellent example. The processor takes two (sometimes three ;-) inputs - XML, XSLT, and an optional set of parameters - does something - and produces an output. You'd expect to be able to use and re-use the processor over and over again. This type of object (imho) has no need whatsoever to be stateful. I'd go as far as saying that it's poor quality engineering. The reason I'm not comfortable with objects being unnecessary stateful has to do with quality. Stateful code - of any description - is non-deterministic, and more prone to bugs. This is especially true over time when many engineers work on the code. Non-stateful code, on the other hand, is deterministic. Same input - same output. You can write unit tests that are more simple, and require less maintenance over time. Given that any comprehensive set of unit tests will take up between 30% and 50% of total development time, that's very important ;-) That's what I mean. Best regards, Stu --