Almost there

[Robert Goldman]

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.
>