This has always been my impression, as well: force-not serves to block force, so should have precedence. I am pretty sure there is a launchpad ticket discussing this. I would be happy to get a patch in to that effect before our long-awaited release.
P.S. I have substantially expanded the number of nodes in the manual, improving the cross-referencing. Had a crisis at work, so couldn't quite finish this (I would like to do one more end-to-end edit), but then consider us good to go.
Sent from my iPad
On Mar 4, 2014, at 1:18, Faré fahree@gmail.com wrote:
As I am writing a parting article (for ELS 2014? ILC 2014?) on the what and wherefore of ASDF3, I tackled the question of force and force-not, and was reminded about that discussion whether I got it right or backward when I gave force precedence over force-not. https://bugs.launchpad.net/asdf/+bug/1184002
Then I retold how force-not was implemented at the request of Erik Pearson, who wanted to be able to declare some systems as "builtin" and not to be reloaded; their code not expensively scanner for upgrades (or worse, for downgrades). Then it came to me: duh, of course force-not should take precedence over force. The use case is clear and clearly legitimate: extending the "base" system such that you can extend it, but not redefine the locked package; yet being able to force some or all of the rest of the system.
I don't see a clear cut case in the the opposite side. Maybe one of you can tell.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The weak terrorist who predictably loses, causing death for those he claims to defend is infinitely more evil than the strong one who wins.