[asdf-devel] Alternate take on the intended use of component-property
rpgoldman at sift.info
Mon Feb 4 02:51:23 UTC 2013
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
(defclass sloc-mixin ()
:type (or (integer 0) null)
(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.
More information about the asdf-devel