Before we all get carried away by too many flights of fancy, let me say that I’m not planning on any radical reworking of adv3Lite to work entirely by signals; nor do I want to risk changing it into adv3ExtremelyHeavy or adv3Quagmire by putting more mechanisms into the core library.
I should also point out that this kind of syntax cannot possibly me made to work in the TADS 3 language:
connect(guard.asleep, cellDoor.openable);
connect(electricity.flowing, stove.canHeat);
connect(tire.inflated, bicycle.canTravel);
What the first of the statements does in TADS 3 is to call the connect() function with the values of the guard.asleep and cellDoor.openable properties passed as arguments; so it would be like calling:
connect(nil, nil);
Which doesn’t establish any kind of relationship that you’d be looking for. Possibly what you had in mind was something like:
connect(guard, &asleep, cellDoor, &openable);
But the thought of trying to make that do anything useful for any arbitrary combination of objects and properties gives me nightmares, as well as bringing to mind:
connect(sledgehammer, crack, nut);
That said, this syntax reminds me of that used to establish relations in the new Relations extension that’s been added to the library for the new release (and is already available from GitHub):
relate(obj1, relation, obj2);
unrelate(obj1, relation, ob2);
It occurs to me further that the original suggestion is somewhat akin to establishing a particular kind of relation between objects, which makes me wonder in turn whether a Signals extension (which I might consider adding to the library) couldn’t be based on making a Signal a special kind of Relation. The basic framework might look something like this:
modify Thing
emit(sig)
{
sig.emit(self);
}
handle(sender, sig)
{
}
;
class Signal: Relation
emit(sender)
{
foreach(local obj in valToList(relTable(sender))
obj.handle(sender, self);
}
;
Then you could do stuff like:
modify Thing
makeOpen(stat)
{
inherited(stat);
if(stat)
emit(openingSignal);
else
emit(closingSignal);
}
;
openingSignal: Signal 'opening'
;
closingSignal: Signal 'closing'
;
// and in some method somewhere:
relate(magicBox, 'opening', dragon);
unrelate(cellDoor, 'closing', prisonGuard);
This is just a rough idea, of course, and it doesn’t cover what happens on the handle() side, but it seems to me to be a possible framework for something that might be feasible on the basis of what’s already in the adv3Lite library.
EDIT: A couple of further points.
On further reflection, I think it would be up to game code to deal with the handle() side of things. Any one-size-fits all solution in the library (or an extension) is likely to prove needlessly cumbersome. Moreover, it should presumably be entirely up to the receiver how it wants to handle any given signal from any given sender. I suspect in many, if not most cases, potential receivers will only be interested in one particular signal from one particular sender, so that a handle() method could be as simple as:
handle(sender, signal)
{
if(sender == safe && signal == openingSignal)
"The alarm starts ringing frantically. ";
}
At the other extremene, if an object needed to handle a large number of combinations of different signals and senders, the best solution might be to use a Rulebook (as defined in the new rules extension added for the next release):
handle(sender, signal)
{
alarmHandleRules.follow(signal, sender);
}
...
alarmHandleRules: RuleBook
initBook(signal, sender)
{
actor = sender;
}
;
+ Rule
who = safe
matchObj = openingSignal
follow(signal, sender)
{
"The alarm starts ringing frantically. ";
}
;
+ Rule
...
One further point: the adv3Lite already issue a great many signals between objects, in the form of beforeAction, beforeTravel, afterAction and afterTravel notifications (plus a few others). There’s no need to duplicate that mechanism. The kind of signalling system outlined above would presumably only need to cater for cases existing mechanisms didn’t cover, which would mainly to be to send signals between objects that would not otherwise normally be connected by the standard notification system, and to provide a means of switching the sending of such signals on and off.