>If I were programming this, I'd write a daemon that monitored the state
>of the water and the dam every turn; in Inform it would look something
>like
>
> Object Dam
> with ...,
> daemon [;
> if (self.water_level > 5 && FloodGates has open)
> ! release the water
> ];
But what would happen if you defined a thousand such constrints using
daemons? Carl's point isn't that the simple example he gave is too hard to
implement in TADS, Inform, or C. It's that a general system that could
efficiently manage dozens of constraints per object would be more
expressive.
I'd agree with him, but I'm not sure how to deal with conflicting
constraints. How do you specify which constraints are checked first? Or
do you impose the rule that no constraint can depend on the result of
another constraint's satisfaction this turn? Offhand, it seems like it
offers programmers the same ability to tangle themselves in knots that a
direct object-oriented approach does. (Though I admit I probably haven't
thought about it enough to have an informed opinion. :)
Dave Baggett
__
dmb@ai.mit.edu
"Mr. Price: Please don't try to make things nice! The wrong notes are *right*."
--- Charles Ives (note to copyist on the autograph score of The Fourth of July)