Hi Erik,<br><br><div class="gmail_quote"><div class="im">On Sat, Aug
 7, 2010 at 6:13 AM, Erik Huelsmann <span dir="ltr"><<a href="mailto:ehuels@gmail.com" target="_blank">ehuels@gmail.com</a>></span>
 wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
moving to CLOS isn't
on the roadmap right now.<br></blockquote></div><div><br> That's fine.<br><br></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


Do you feel you have a need for the library to be CLOS based? If so,<br>
could you explain your use-case?<br></blockquote></div><div><br>It is 
not a need, only a wish.  If the original intent to use CLOS was still 
there, it would get my support.<br><br>I see some potential benefits to 
using CLOS, largely because it offers an easy protocol for extending and
 customizing behaviours:<br>
<br>* 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;<br><br>*
 Generally, being able to plug methods around getters and setters can be
 useful for applying additional validation and constraints;<br>
<br>* Customizing object initialization can be similarly useful (e.g. 
plugging in an early check for a rule, that may signal a restartable 
condition);<br><br>* Customizing printing (see next point);<br><br>* 
Most importantly, subclassing to group such specific extensions is more 
flexible, permitting modular design of client code.<br>
<br>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.<br><br>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.<br>
<br>[1] <a href="http://gitorious.org/py-configvalidator" target="_blank">http://gitorious.org/py-configvalidator</a><br><br>Thanks<br><br> </div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


<br>
Bye,<br>
<br>
<br>
Erik.<br>
<div><div><br>
<br>
On Fri, Aug 6, 2010 at 5:44 PM, Abhishek Reddy <<a href="mailto:arbscht@gmail.com" target="_blank">arbscht@gmail.com</a>>
 wrote:<br>
> Hi,<br>
><br>
> A comment in config.lisp suggests that structs are used instead of 
CLOS due<br>
> to an issue with ABCL as of 2008.  Has the situation with ABCL 
improved,<br>
> given its substantial development since then?  If so, would it make
 sense to<br>
> abandon structs for CLOS in py-configparser?<br>
><br>
> --<br>
> Abhishek Reddy<br>
> <a href="http://abhishek.geek.nz/" target="_blank">http://abhishek.geek.nz</a><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> py-configparser-devel mailing list<br>
> <a href="mailto:py-configparser-devel@common-lisp.net" target="_blank">py-configparser-devel@common-lisp.net</a><br>
> <a href="http://common-lisp.net/cgi-bin/mailman/listinfo/py-configparser-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/py-configparser-devel</a><br>
><br>
><br>
</blockquote></div></div><br><br clear="all"><br>-- <br>Abhishek Reddy<br><a href="http://abhishek.geek.nz/" target="_blank">http://abhishek.geek.nz</a><br><br>