[asdf-devel] Alternate take on the intended use of component-property

[Robert Goldman]

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