Re: Oh no! No #'slot-value-using-class?

[missing@inch.com (Ken Tilton)]

>> Did not see it in apropos (or Steele!), either.
>
>MOP is not in CLtL (any version) or ANSI-CL.
>
>> I wanted to play a little game with slot-values, hiding it from the
>> programmer (me!). I was going to use a dotted pair in each slot. The car
>> would be the value. If nil, the cdr would be a lambda capable of
>> calculating the value, which would then be cached in the car. I was going
>> to use 'reinit... to explicitly clear car's when circumstances required the
>> calculations be made afresh.
>
>You can get the effect you want via methods on slot-unbound that use the
>slot name to look up the lambda in a side table, with reinit calling
>slot-makunbound.  No need for slot-value-using-class here.

Ah, that would work. Thanks. But I was hoping to get the behavior
automatically for any slot added to such a class. (I could probably make
the side-table work automatically, but not efficiently.) I also like the
idea of bundling the value and lambda in a single cons that could be passed
around to various functions.

Hey, this is fun! I find I am spending more energy on silly schemes like
this than getting my app out the door (and hoping the two go together. <g>)

For now I'll just make up a getter for each slot that hands off the query
to my own get-cache-or-calc-value function, so I can keep the pair bundled.
Then I will probably to a class-defining macro that takes a class-name and
slot-names and spits out a defclass and a bunch of defmethods.

Just checked Bill's note relaying the source for s-v-u-c. Oops. I better do
more browsing. But I take to heart the warning that it slows everything
else down. I kinda figured that's why it might not be there in the first
place--performance. I don't want to lose that.

Thanks, Kim.