I’m dropping some I6 code into a kind/class definition of I7, and what would normally be the I6
self object doesn’t seem to be set properly. For example, the code:
A Foo has a number called bar. The bar property translates into I6 as "baz".
print "Self object: ", (the) self, " / ", self.baz, "^";
when defining a Foo.
There is a Foo called example. The bar of Foo is 4. It is in Starting Room.
gives garbage like
Self object: <routine 78800> / [** Programming error: tried to find the "." of (something) **]
[** Programming error: tried to read (something) **]
at runtime (and, in particular, refers to a routine rather than object). The I6 code the compiler spits out looks reasonable enough, and what I think is the native I6 version of the code above runs without issue. It doesn’t look like
found_in should cause any problems (and it’s there mostly because it’s an easy way of triggering the error), or at least something of this nature. So, is this the correct way of injecting I6 code into a class definition; and if so, why is
self seemingly garbage?
That is the right way to add I6 code, but that doesn’t mean the code will work. The I7 library doesn’t handle all I6 properties in the normal I6 way. In this case, it doesn’t set
self before calling the
The full explanation:
The I6 library has a routine MoveFloatingObjects(), which is called every turn. It runs through all floating objects (those with a
found_in property) and looks at that property value. If that value is an object, it uses that for the location check. If the value is a function, it calls
(I’m simplifying somewhat here but that’s the relevant bit.)
The I7 kit code (WorldModel.i6t) has a similar MoveFloatingObjects() routine, and it does roughly the same thing, but it’s not identical. In particular, it assigns the
found_in property to a local variable
m. If that’s a function, it calls
r is the destination being checked.
So why is that different? Because it’s the
i.found_in() syntax that sets
self for the call! If you do
m = i.found_in; m(); then
self is not set. And the I7 kit code is written that way.
It’s normally fine because I7-generated
found_in functions never refer to
self. But you violated that assumption.
So can you get what you want? Only by replacing MoveFloatingObjects() and adding a line to set
I’ve gotten burned with
MoveFloatingObjects often enough to be aware of how they work in I6, but I didn’t know that the world model in I7 implements a different setup. Thanks, that’s something I can easily work around.
Should I assume that object functions aren’t necessary called from the object in question in general when injecting I6 code? Or, more generally, is there a reference for the assumptions I shouldn’t violate?
Read the kit code. That’s what I did.