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

[Faré]

Dear Dan,

On Fri, Feb 1, 2013 at 5:03 PM, Dan Lentz <danlentz at 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