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?
Regards, Dan.
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
Dear Dan,
On Fri, Feb 1, 2013 at 5:03 PM, Dan Lentz danlentz@gmail.com 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.
I haven't heard of anyone using component-property that way, nor is there evidence of anyone doing it in quicklisp. Should you ever need to associate data to systems, make-hash-table is not too far away.
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?
That's an issue with CLOS in general. I don't believe that it is ASDF's job to insert a backdoor into its class to allow for people who are unsatisfied with CLOS to avoid using it when writing ASDF extensions. Just like I don't believe it is ASDF's job to use a gross workaround of a temporary package to gloss over the fact that packages are a poor namespace management system. If you can't deal with these limitations of Common Lisp, you should be either extending Common Lisp or using a different language altogether.
And yes, if you want to extend each and every class in ASDF, you might be having a problem. Not my problem though, and I don't have to sacrifice the consistency of my software's architecture for the sake of hypothetical users who never materialize. If you have bright ideas on how to make extensions of ASDF that require deep hacking of it, you can easily override ASDF definitions, just like we at ITA did in the bad old days of ASDF 1. Beware though that if your hacks are deep and pervasive enough, yet are justified by the benefits they bring, you might find yourself merging them into ASDF itself and becoming the next ASDF maintainer.
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?
I challenge you to describe such a situation.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Fall in love with some activity, and do it! Nobody ever figures out what life is all about, and it doesn't matter. Nearly everything is really interesting if you go into it deeply enough. Work as hard and as much as you want to on the things you like to do the best. Don't think about what you want to be, but what you want to do. — Richard Feynman
-
Dan Lentz -
Faré -
Robert Goldman