Referring to the object that has a shuffled event list

My class has a shuffled event list. Instances of this class will use the shuffled event list to spit out atmospheric text in certain circumstances. It would be nice to attribute this text to the specific instance that is responsible for it.

What I want is something like this:

[code]
class Mime: Person
CaperList: ShuffledEventList
{
[
‘<.p>^’+theName+’ capers in a disconcerting fashion.’
]
}
afterAction()
{
“<<CaperList.doScript()>>”;
}
;

someLocation: Room ‘A Room’
;

+Mime ‘tall mime’ ‘tall mime’
;[/code]
Which will output:

But it seems that “theName” in this context refers to the theName of the shuffledEventList, which is nil. What do I need to make this work?

UPDATE: Okay, Learning TADS 3 suggests “lexicalParent.theName”, but this refers to the class itself and not the instance. As it happens, I did have some vocab set at the class level, but I really want to see “the tall mime” and not “the mime”.

UPDATE the 2nd: So an obvious duct-tape solution is just to store the current object in a global variable at the start of the afterAction, and then refer to that variable in the ShuffledEventList. This works, but I’d be interested to know what the canonical solution is.

Don’t simply use a list in the class, but actually inherit from it. That way, you can refer to the properties/methods of the class directly through ‘self’. And that means that when you create objects (=instances) of that class, ‘self’ refers to the object, not the class.

How about this?

class Mime: Person
    CaperList: ShuffledEventList
    {
        [
            '<.p>\^'+theName+' capers in a disconcerting fashion.'
        ]
        theName = ''
    }
    afterAction()
    {
        "<<CaperList.doScript()>>"; 
    }
    initializeThing()
    {
        inherited;
        CaperList = CaperList.createClone();
        CaperList.theName = theName;
    }
;

+Mime 'tall mime' 'tall mime';
+Mime 'short mime' 'short mime';
+Mime 'fat mime' 'fat mime';

EDIT: changed the way that CaperList is initialized.

This would also work, and is pretty close to your original solution of using a global. Here we exploit the fact that we change ‘theName’ on every new object of class Mime, and pass that altered value into the parent’s CaperList.

class Mime: Person
    CaperList: ShuffledEventList
    {
        [
            '<.p>\^'+theName+' capers in a disconcerting fashion.'
        ]
        theName = ''
        doScriptFor(me)
        {
            theName = me;
            doScript();
            theName = '';
        }
    }
    afterAction()
    {
        "<<CaperList.doScriptFor(theName)>>"; 
    }
;

+Mime 'tall mime' 'tall mime';
+Mime 'short mime' 'short mime';
+Mime 'fat mime' 'fat mime';

The earlier approach is more suitable when you want objects inheriting from the class to have their own, independent instance of a nested object without having to override that property for every new object.

My understanding is that TADS objects are created as shallow copies of the parent. The only properties stored separately in memory are the ones you override. Unless you intentionally create a new CaperList object for each mime, they will all use the one nested in the parent object. So lexicalParent is of no help because it will always refer to the class object rather than the game object.

This is not necessarily intuitive; I’ve persisted in thinking of TADS classes as insubstantial archetypes, though the manual takes pains to stress that the only difference between a class and an object is that the former is ignored by the parser.

Thanks for the responses, you two.

That seems cool (if a little hard to think about in the typical “is a/has a” way), but what if I want each class to have multiple lists of things? (Could you provide an example?)

Neat idea, but the idea of defining all the lists in their constructors seems like it would result in pretty ugly code to me.

I like it. I might use it if I need to get more parameters to the list. As it stands, I think I’ll stick to the global variable, since I need to keep track of my mimes somewhere anyway.

I think this is something that has confused me before, so thanks for the explanation.

Also, I am kind of wanting to have my cake and eat it, since I want the shuffled event list to serve up different responses universally, while referring to specific objects. So I wouldn’t want to see two different mimes caper in the same way one after the other.

I’ve edited the original post to reflect a different way of handling it. It reads better and is slightly more efficient, since each mime’s CaperList differs from the original only in the ‘theName’ property.

I agree that having all the mimes caper through the same mechanism (rather than three independent ones) makes it easier to collate responses into more readable prose. So for your purposes the second approach is still superior.