Hi Erik,

On Sat, Aug 7, 2010 at 6:13 AM, Erik Huelsmann ehuels@gmail.com wrote:

moving to CLOS isn't on the roadmap right now.

That's fine.

Do you feel you have a need for the library to be CLOS based? If so,

could you explain your use-case?

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-configvalidator

Thanks

Bye,

Erik.

On Fri, Aug 6, 2010 at 5:44 PM, Abhishek Reddy arbscht@gmail.com wrote:

...

Hi,

A comment in config.lisp suggests that structs are used instead of CLOS

due

...

to an issue with ABCL as of 2008. Has the situation with ABCL improved, given its substantial development since then? If so, would it make sense

to

...

abandon structs for CLOS in py-configparser?

-- Abhishek Reddy http://abhishek.geek.nz

---

py-configparser-devel mailing list py-configparser-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/py-configparser-devel