On 7/15/15 Jul 15 -2:23 PM, Attila Lendvai wrote: >> Well, if we change the API to add a boolean slot to SYSTEM, we could > > this may be naive, but what i meant is a very simple change: > introduce an exported SYSTEM-MUTABLE-P, together with a SETF version, > that messes around with the current hashtable based implementation.
I looked at that, but it looks like the actual code fuses a bunch of stuff about *looking up* a system (the system argument is a system name) together with actually making the system immutable. I think if we were to do what you want, instead of doing a half-way job by just renaming what's there and adding a SETF method, it would make a lot more sense to decouple the lookup from the setting, and have SYSTEM-MUTABLE-P take a real *SYSTEM* as argument, instead of having an odd API where only a system-NAME is acceptable. Then there's the question of what to do with the :VERSION argument when we pass a real system, and when SYSTEM-IMMUTABLE-P is used in a query mode. I started banging on this, and the alarm bells for "this is an ill-thought-out hack that you will regret later" began to go off. So I'd prefer to do a good job of this, later, instead of digging myself another hole I'll have to fill in later. I think having a confusing name that we deprecate is better than taking the good name, and implementing something bad on it. This way we can think about a better API and put the better API on the better name. Best, Robert > > IOW, it's pretty much just a rename of REGISTER-IMMUTABLE-SYSTEM -> > (SETF SYSTEM-MUTABLE-P), and a new SYSTEM-MUTABLE-P that queries the > internal hashtable. the (setf ... false) version may be a > not-yet-implemented error if there's too much state to mess around > with before this release. > > moving to a slot based implementation is another story that can be > delayed, and may not even be preferable (e.g. what if someone > sometimes wants a set of systems to be immutable, and some other time > not? although, this also applies to every slot of SYSTEM, so...). > >> remove REGISTER-IMMUTABLE-SYSTEM, and make it the responsibility of >> the user to create the system, whether through >> register-preloaded-system or not. Actually, if the slot has an initarg >> keyword, then you can use register-preloaded-system directly to create >> an immutable system if not already present, or you'll have to use setf >> to make an otherwise existing one immutable. >> >> I'd rather you just release what we have for now, but if you want, I >> can make those changes before 3.1.5 (or after). > > another alternative is to just keep all these symbols private and > delay their exporting. optionally multiple variants could be added but > not exported, so that early adaptors can already use the > to-be-published API by using ASDF:: prefix. probably it's only the two > of us participating in this thread who are using this new feature. > > an untested sketch is attached that merely renames what's already > there, and errors at (setf ... false). > > but to reiterate: i don't have hard feelings about this. i'm just > trying to help avoiding the publishing of a confusing name that will > be much harder to change down the road. >
