Forum OpenACS Development: Re: Require TIP for callbacks?
Openacs is already quite good in managing core assets (packages, versions, dependencies) via the database. A development towards managing the installation assets over the database would be great and could certainly ease change management for installations significantly. However, to implement such product lines require architectural support and guidelines how to handle and track local modification in which situation to standardize the change management. The support should as well contain support for testing of the adapted installation assets.
Callbacks were primarily invented for disruptive control flows (e.g. in event handling, application semantics for GUIs), not for configuration issues. Be aware, that many problems we have today in configuring oacs can be handled with standard oo techniques such as subclassing. On top of that the strengths of xotcl are in terms of flexibility through mixins and filters, which are means to implement e.g. aspect oriented constructs. So, we are in a good shape to build a really good environment to handle installation variability. On the short range, callbacks are maybe a good tool to handle variability now. On the longer range, they won't make it easier for the sketched next level.
Since Don has reminded everyone that query-writer will never be used in OpenACS core (thank god, I'd hate to fight against changes to it), I'll just mention that query-writer is even closer to the CLOS system than xotcl in this respect. query-writer uses generic functions for new/set/del/rst operations. At the moment there are only a few callback points. One just after all the input attributes have been validated, but before the object operation. This is used to do cross attribute validation or to otherwise combine attribute parts into one. There is also an original block of code that can be run just before the object action. Another point is just after the object action.
It looks like xotcl could be used in a similar way around any proc. Both method lends themselves to reducing code complexity. I'm not sure that adding callbacks _into_ a proc body achieves the same goal, personally I can't tell the difference between that and just inserting a new function call inside the procedure. Regardless, neither could be called configuration. Calling two things (or behaviors) by the same name is usually the beginning of disaster. Probably worse than having to maintain 15 different versions of code is constantly having to having to adjust code which used to work perfectly well, but now doesn't.
Using powerful language constructs can be very constructive or very distructive. Some languages are designed to limit the harm, a bad progammer can do. Some other languages are designed for empowering the power-users. xotcl was certainly designed for the seconds category, where a good design can be achieved with a few statments (the initial goal was to provide language constructs for design patterns, for adding and removing these dynamically). no language guarantees quality, quality control is needed always. It certainly makes no sense to use every language construct in every situation.
My point was not to talk about xotcl, but about product line architectures, about ways to manage variablility in code installations, which is a serious problem in complex real life situations.