Faré fahree@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