[asdf-devel] component-property
Zach Beane
xach at xach.com
Thu Jan 31 17:45:24 UTC 2013
Faré <fahree at gmail.com> writes:
>>>>> On the one hand, I am deprecating component-property in ASDF3,
>>>>
>>>> Why? What will be the new mechanism for what component-property
>>>> provides?
>>>>
>>> I propose that any data that component-property is actually used for
>>> should be in appropriate slots of the system.
>>
>> This will introduce a new round of synchronization headaches whenever a
>> new slot is added. The existing mechanism is forward and backward
>> compatible indefinitely.
>>
> Synchronization is NOT necessary to add new slots.
> If you want a new slot, just create a new class with that slot,
> and use both :defsystem-depends-on and :class in your defsystem form.
> This usage pattern wouldn't work on ASDF 1 or early ASDF 2, but
> it works quite well since ASDF 2.016 from June 2011 and later.
> Then, a year after your slot gets merged into asdf:system,
> you can stop using your defsystem-depends-on.
Feel free to adopt this technique for your proposed website slot, so it
does not cause compatibility problems. Please do not remove other
techniques.
> The properties mechanism is already totally and irremediably useless.
> Automation across systems is impossible unless everyone agrees on a schema,
> or you somehow merge the zillions of possible ad-hoc schemas; but
> properties actually make synchronization *harder* than lack thereof,
> by making it cheaper to diverge and more expensive to converge.
> Properties without a synchronized schema are useless within a single system,
> where it is easier, safer and more powerful to just directly store data
> in a Lisp variable rather than in the properties.
>
> In other words, properties not only do not serve the purpose
> they look like they are addressing, but cannot possibly serve any purpose.
> They are a lure and a waste of everyone's time — an attractive nuisance.
I think it would be pretty easy to get everyone to agree on a schema for
properties, and it would be useful to do so.
Zach
More information about the asdf-devel
mailing list