No schmancy movies today. You'll have to use your imagination.

I spent some more time on the NamedSlots stuff this evening. It's interesting how when we make an object of something (i.e. cordon of a chunk of data that we can bind specific behavior to), all kinds of possibilities start opening up to the imagination. I've got a slew of them. But this evening, I roughed out the implementation of what started me thinking about this stuff in the first place.

Ever wanted to add an instance variable to an object? I know people like adding them to the RefactoringBrowser. One of the biggest headaches I had in doing the changes done for 7.6, was the various 3rd party hacks that like to add an instance variable or two to RB classes. To do this, you override the class definition. Since you do this be overriding the class definition message basically though, not only are you adding your new instance variables, you're unchanging any changes made elsewhere in other parts of the class definition. It's basically too big of a chunk of information. There's probably multiple ways to solve this, but I chose to follow the mantra "It's all in the messages" and thanked Vassili all along for giving us method tag facilities (pragmas) to know which messages it's in. The basic idea is that rather than list your instance variables as a white space separated list of tokens in a simple string, we use methods to define them. E.g.

someOfMyInstanceVariables

    

    ^#('x' 'y' 'z')

instVarForScaling

    

    ^#('w')

So I sat down and wrote tests, and then made the code do exactly that. It was a fun adventure in meta meta programming. It gets confusing whether your an #instance method tag, or a #class method tag as you approach the Metaclass Knot. The code's all published (NamedSlots, NamedSlotsPreLoad, NamedSlotsTests). It's currently a pretty trivial implementation, it doesn't do shape changing--yet. I did do the though. It coexists fine with all of the existing defined instance variables fine. It appends these at the end of said list.

The nice thing about this, is that as we make more and more of the system consistently built from the same uniform pieces, tools and such get simpler in the long run. We don't need to implement a whole system and algebra of adding and removing instance variables. We just use the facilities already provided for method management.

One open question is how to deal with the smattering of instance variables whose position is known to and exploited by the VM. The fact that the "methodically defined" instance variables coexist fine with the former ones keeps all happy for now. But in an ideal world, you'd do all instance variable defines methodically, and then you need an extra piece of information to manage specific placement.

I'll try to robustify this up soon, and then we'll see what other avenues open up.