It is
not a need, only a wish. If the original intent to use CLOS was still
there, it would get my support.
I see some potential benefits to
using CLOS, largely because it offers an easy protocol for extending and
customizing behaviours:
* I believe the name-transform functions are special cases of what
could be a method combination on the reader of a name slot; and it may
also be useful to denote them separately from the constructor call;
*
Generally, being able to plug methods around getters and setters can be
useful for applying additional validation and constraints;
* Customizing object initialization can be similarly useful (e.g.
plugging in an early check for a rule, that may signal a restartable
condition);
* Customizing printing (see next point);
*
Most importantly, subclassing to group such specific extensions is more
flexible, permitting modular design of client code.
Of course, one can work around structs to achieve the same sort of
results, but I think it may be simpler and easier to do it the CLOS way.
In
practice, I have written a validation layer[1] for py-configparser,
which arguably suffers some mismatch where I have wrapped the structs
and several functions. Such extensions might be integrated more neatly
if the basic API used CLOS. Generally, when using py-configparser, I
find myself writing ad hoc wrapper functions for specific
transformation, validation and printing behaviours, whereas to subclass
and appropriately specialize a generic function might be a better style.
[1]
http://gitorious.org/py-configvalidatorThanks