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.