I am pleased to announce the first draft of a new extension I have written: Mutable Kinds.
Mutable Kinds allows you to change the default values of properties at run time.
I’m happy that I have got it working, but I’m not too happy with how it works. It will not have great performance as it essentially duplicates the properties system. An I6 object is created for every I7 kind, but it doesn’t actually have any properties, so I can’t use it as I would have preferred. Any ideas for improvements?
Interesting. If I understand correctly, when a property is at its default value, any I7 property read will intervene and return a value from a writable array instead? I’m curious to know the situation that motivated the hook.
I haven’t looked too closely, but here are a few comments:
The name Dynamic Kinds'' makes me think that the extension will let me write things likenow the table is a door’’. Maybe something like ``Mutable Default Properties’’ would convey the purpose better?
This behavior strikes me as unintuitive:[code]Include Dynamic Kinds by Dannii Willis.
Shop is a room.
A clock is a kind of thing. There is a clock.
A clock has a time called now. The now of a clock is usually 10:00 am.
The sundial and the grandfather clock are clocks.
The now of the grandfather clock is 10:01 am.
When play begins:
showme the now of the sundial;
showme the now of the grandfather clock;
increment the now of the kind of clock;
decrement the now of the grandfather clock;
showme the now of the sundial;
showme the now of the grandfather clock.[/code]
3. Should either/or properties be handled symmetrically, so that we can write things like ``now the kind of clock is on’’?
I want to rewrite the scrolls code of Kerkerkruip so that it can have a kind for each type of scroll rather than cloning scroll objects, and so that their secret names can be assigned to the individual scroll kinds. And now I’m doing it for the challenge too.
Hmm. It wouldn’t be impossible to make “now the table is a door” work, though it would certainly be messy. Far messier than this is. I had thought about calling it “Mutable Kinds”…
What do you find unintuitive about it?
I think so. Does that not work? I admit I haven’t tried it yet. Edit: Of course they don’t. I’ll have to hack GetEitherOrProperty() and SetEitherOrProperty() too.
Ah, I figured it was something to do with Kerkerkruip, though I guess I should clarify my curiosity. I’m wondering what snag code like ``now the secret name of every scroll labelled hermei le schim is “scroll of death”;’’ ran into.
Regarding the comments, the mental model I’m getting from the extension is that, if we have a kind K and a property P, we can bin objects into those that have their P values overridden and those that do not; we want to treat these bins differently. All of the objects in the second bin share a value for P, so we’ll think of this value as belonging to K rather than the objects. This is where the name threw me: in vanilla Inform, K only has a default value for P at compile time. From the title, I expected the extension to make some existing runtime concept mutable, but, in fact, it’s introducing the concept of K’s runtime P value and then allowing that the change.
As for point 2, what seems odd is the way that objects transfer membership from one bin to the other. It makes sense to me that, if we alter an object’s property in the usual way, that property will be overridden, and the object will fall in the first bin. But there’s a notable exception: if we try to override a property with the original default value, we actually move the object to the second bin, un-overriding the property. For example, suppose I want most clocks to run forwards, but have the grandfather clock run backwards. When the grandfather clock winds its way back to 10:00, it suddenly becomes a normal clock for a minute, and the time it displays will jump. The only way to have it show 10:00 is for all of the normal clocks to reach that value at the same time. In the extension’s example, that means that, with enough patience, I can make the machine stop the watch watch’s time jump.
Hmm. That might be possible, if it is I’ll probably do that for Kerkerkruip. But someone else may find this extension useful.
The problem is however that the code which reveals a scoll’s name won’t know the kind of the scoll… but I guess we can work around that by using the KD_Count property and an I6 equivalent of “every”.
Your point 2 is a valid one, and I’m not sure what to do about it. It would be easier if there was an I6 null.
Oh, I think I see. In the now-every case you would want some way to write let K be [expression yielding kind];
now the secret name of every K is "..."; Hmm. Interesting.