Pseudo-methods for Pseudo-object-oriented programming was me briefly thinking I was clever for shoe-horning a way to sort-of do methods in I7 and having it gently pointed out to me that I7 had a good way to do that already.
So for your Size example, I’ll assume that size-value is a kind of value.
Sizing is a thing based rulebook producing a size-value.
To decide what size-value is the size of (t - a thing):
decide on the size-value produced by the sizing rules for t.
Sizing a shirt (called the garment):
[...]
Sizing the tuxedo t-shirt:
[...]
Like @Draconis said, you might waste some space by assigning properties to all things. But if you don’t have complicated dependencies on extensions, you could also do:
A garment is a kind of thing.
A garment is always wearable.
And then assign your specific properties to garment and loop through garments instead of wearable things.
I actually like the rules-based approach in principle, but the main problem I have with it is the one he mentions at the end of his presentation: There’s no notion of encapsulation for rules. Sure, I can define rulebooks and move individual rules into them, but ultimately all of these rules are sloshing around at the global level. How do I know which rules could potentially apply a given game object? (If the answer is ‘all of them’, then coding and debugging the game is going to be pretty difficult.) When I use someone else’s external library, how can I be sure it’s going to place nicely with the code I have? What’s the precedence for rules? (The documentation lays out its idea for a hierarchy, but it’s quite complicated; and given some of the other unpredictable quirks of I7, I’m not sure I actually believe it.) Rules don’t necessary just replace a command completely or fail; there can be a complicated feeding order. And so on.
Well, yes, I7 has poor encapsulation in general. And that is problematic for extensions and has limited their utility somewhat. Looking at published games’ versions, it seems like a few expert authors use dozens of extensions at a time and most everyone else uses zero to two. Most extensions are fairly short and easy to read and you can eyeball potential problems… but some aren’t.
Have you spent a lot of time debugging rule order problems? As a long-time programmer I was really, really dubious of the “More specific goes before more general and most of the time that’s good enough and you don’t have to worry about it” thing. I expected huge amounts of nuisance specifying exact orders for rules. And one of the things I’ve found really astoundingly amazing about I7 is… most of the time “more specific goes before more general” is good enough and you don’t have to worry about it. I slap first and last on things sometimes but have only rarely had to be explicit about “Rule X is listed before Rule Y”, other than modifying existing sequences like the turn sequence.
Have you spent a lot of time debugging rule order problems?
In some cases, yes. It’s uncomfortable to deal with the idea that I7 programming involves just hoping that the I7 internals happen to decide to the right thing. I know the language comes in with the explicit ideology that interactive fiction is a narrative primarily and only code secondarily, but I can’t shake the feeling that it has a fairly tight upper bound on the amount of complexity that can be comfortably put into a game (at least, without spending far more time and play-testing rounds on it than I’m willing to). And sure, no one is looking to code the next version of emacs in I7; but given the other idiosyncracies and general weirdness of I7, I’m not willing to just trust that everything will work out, and I don’t see any convenient way of testing all of it.