On 2/1/13 Feb 1 -4:03 PM, Dan Lentz wrote:
I was always under the impression that the intent of C-P was to provide a means of annotation primarily to be used at runtime by the ”end-user". For example, say if one were interested in some type of statistic, say SLOC, for comparison and analysis of a (possibly large) number of systems, One might conveniently calculate and store that value as the :SLOC property within each component while being visited, and then aggregate the result at some later time. Deprecating the expectation of standardized property access for use by the actual day-to-day developer working with asdf systems would seem to lead to a profusion of half-baked off the cuff "solutions" reimplemented each time such a need presents itself.
Also, the property slot is a direct slot of component, very early in the hierarchy, and so is transparently inherited by each increasingly complex subclass of component on upwards through the class hierarchy. Are you saying that if one needs it then one should subclass component to include some property slot, and also then subclass module likewise, and then system also, etc? So to get this scratchpad working space means essentially one needs to reimplement the whole asdf class hierarchy?
FWIW, I think there are many situations in which the component-property provides a more sensible facility than would ad-hoc archetypal extension of ASDF's fundamental object model. Am I misunderstanding the proposed changes?
Can you amplify on this a bit? My colleagues and I have frequently extended the object model of ASDF. It's pretty trivial. There are really two cases:
1. You only need an extension for a single system. In this case you will typically be extending whatever file class is used (usually cl-source-file). It's trivial to define a subclass and add new slots.
2. You are extending ASDF a great deal. Then we typically make a new system class, a new file component class, and add slots as necessary. A little more fussy to make sure that you DEFSYSTEM-DEPENDS-ON this new system you have made, but still no big deal.
I really don't understand what you mean by:
one should subclass component to include some property slot, and also then subclass module likewise, and then system also, etc?
For your SLOC example (I'm assuming this is what you mean here), you could do:
(defclass sloc-mixin () ((sloc :type (or (integer 0) null) :accessor component-sloc )))
(defclass sloc-cl-source-file (cl-source-file sloc-mixin) ())
(defclass sloc-module (module sloc-mixin) ())
(defclass sloc-system (system sloc-mixin) () (:default-initargs :default-component-class sloc-cl-source-file))
Actually, I'm not sure even that's needed....
If you are rolling this up, you could simply make sloc-mixin for the source-file and add a method at MODULE to roll up results from children. And SYSTEM is a subclass of MODULE, so the roll-up would come right up to the top.
Now, if you want to do this on arbitrary systems w/o redefining classes, that would be more tricky, but it's not rocket science --- you'd need to create some ancillary data structure (hash table?) while traversing the system. It's the same trick you'd use to, e.g., add a VISITED "property" to some data structure that you were treating as if it was a graph, and searching.
Best, r