>>>: Xach >>: Faré >: Xach >>> I request a slot called "properties" that can hold arbitrary key/value >>> data. >>> >> If it's arbitrary, it's not usable from one system to the other, and >> thus serves no purpose. > > I don't understand this, sorry. > > Imagine that there was a community desire to provide, in a system, the > answer to the question "Where is the best place to go to report bugs for > this system?" > Doesn't require a lot of imagination. Then we add a new slot for that.
> It is possible, today, to choose a key (or set of keys) for a property > stored in the system, and for authors who wish to participate to adopt > the convention, and for some tool to gather this information and provide > it in a useful way. > There's already a perfectly fine feature for free-form metadata that follows loose conventions impossible to process automatically. It's called comments. Contrariwise, class slots are supposed to hold information suitable for automation following sufficiently agreed-upon protocols. > I don't see how this is not usable from one system to another. > Different names for the same thing, or same name for different things. Automation is hell if possible at all. A disservice to the community. > It does not require reader conditionalization, subclassing, or ASDF > upgrades. It can be expanded and changed without expansions or changes > to ASDF. It works with past versions of ASDF, present versions of ASDF, > and until today, I thought it would work in future versions of ASDF. > It still requires agreement to an actual specified protocol to be useful, but it creates the false sense that cooperation is possible without such. Out of the existing uses of :properties, the only properties that are usable by more than one system are the albert things. Interestingly, they are not a protocol allowing for multiple software to cooperate, but only the internals of a single system, and would be better served by an albert-system subclass of system. None of these properties otherwise "works" in any meaningful way as a convention followed by multiple parties. Remarkably, automation still requires software to be written, and does not retroactively happen in old versions of the software. > I'm not sure why this is an undesirable feature that must be removed > from ASDF. > I don't see any feature being removed. I see features being added, and a bug being removed that lures developers into believing they are cooperating with others when actually they aren't. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There are a thousand hacking at the branches of evil to one who is striking at the root. — Thoreau _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel