String Attributes: Do's and Don'ts

[tajmone]

Clarify better string attributes do's and don'ts, their design intended vs other potential uses and the potential pitfalls.

See alan-if/alan#10 for Thomas detailed explanation on the topic.

• In §3.7 » Numeric and String Attributes expand on string attributes usage do's and dont's:
  • Mention difference between inline strings and attribute strings (the former being stored in the storyfile and retrieved on demand, the latter being stored in memory).
  • Emphasise more that string attributes on classes should be avoided since (like all attributes) they are copied into all instances of all subclasses.
  • Mention that attributes initialization is done at game start, and that very long string attributes on classes could delay game start due to initialization propagating them on all instances of all subclasses.
  • Mitigate and better contextualize the potential memory/performance issues on modern computers.
  • Find a way to emphasize the original design motive for string attributes (i.e. "saving string parameters from the player input") versus other usages found in real-case scenario (e.g. library messages storage) — drawing a line between the intended use and the potential side uses, and mentioning where the grey areas are.
• In §6 Hints and Tips (either in §6.1. Use of Attributes or a new dedicate section) provide tips and examples of how string attributes could be used to store adventure or library messages on some dummy location to:
  • Centralize message strings used by multiple Verbs/Events, to avoid repetition and simplify changing all the occurrences in a single place (DRY vs WET approach).
  • Store reusable text snippets that occur in many verb responses (e.g. "you can't $v $1") and the pros and cons of this approach (e.g. storyfile size vs memory usage, etc.).
  • Provide practical code examples of good and bad string attributes usage.
  • Provide some rules of thumb.

The Alan Manual mentions in §3, under Numeric and String Attributes:

Note that string type attributes are mainly intended for saving string parameters from the player input, like in:

> scribble "Kilroy was here" on the wall

They are not intended for storing long strings of descriptions, especially not as attributes to classes, as they (in the current implementation) require memory and take time to initialise when starting the game.

Yet, the StdLib makes ample use of string attributes (defined on the mygame location) to store verb responses shared across multiple verbs.