Found_in equivalent in I7

I’ve checked it out, and it remains the case that either-or properties or truth state properties given a ‘… translates into inter as…’ or ‘…translates into I6 as…’ line compile by default to I6 attributes. So doesn’t help this situation, unfortunately.

Huh. I didn’t think that would be the case. That’s good to know.

If you know it’ll be an attribute, can you just [; return real_location has buckety; ]?

That’s true in a given known instance (and, to be fair, for most practical instances) but the the ‘purist’ problem in general is that should the Inform compiler run out of I6 attribute slots it will without warning start to compile binary I7 properties as I6 properties. I guess that’s a particular consideration for extension-writers…

Seems to work in the code I posted above? Trying to expand I7 adjectives with (+ I7_adjective +) doesn’t seem to work in 10.1.2 tho. I’ve filed a bug report.

But this won’t compile in 10.1 and works in 9.3/6M62

lab is a room.
mouse is a thing in the lab. mouse has a number called age.

When play begins: 
now the age of mouse is 12; 
foo mouse;


To foo (o - an object): (- Foo({o}); -)

Include (-
[ Foo o;
print o.(+ age +);
];
-)

I’d be tempted to say that anonymous properties work and named don’t, but this also works in 9.3/6M62 and fails to compile in 10.1:

lab is a room.
mouse is a thing in the lab. 
color is a kind of value. the colors are red, green, blue.
a thing has a color.

When play begins: 
now the color of mouse is green;
foo mouse;


To foo (o - an object): (- Foo({o}); -)

Include (-
[ Foo o;
print o.(+ color +);
];
-)

So I don’t know what’s going on.

It seems to depend on context what will work and what won’t. For I7 object names, they expand correctly in I6 functions but not in I6 properties; for I7 property names they expand correctly in I6 properties but not in functions; for I7 adjective names I haven’t yet found a context where they do expand correctly.

I think the overall conclusion is that the hybrid I7/I6 coding environment is multiply broken in unpredictable ways in 10.1.2 and will remain unreliable until or unless @GrahamNelson finds the time and/or inclination to fix it. Of course, since his general paradigm is to try to discourage hybrid coding, this may not be a priority for him, although it does mean a significant codebase no longer compiles in 10.2.1.

As far as I can see so far, the system for translating names from I7 to I6 and using the thus-known translated forms in I6 code as an alternative to expanding I7 names still seems to work, although that doesn’t help for adjectives, which can’t be translated.

2 Likes

Ah, true. I suppose a good stopgap would just be to bring back GetEitherOrProperty, and then we don’t need to care about the implementation details of attributes vs properties.