Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provide an API for ordering of IDescriptionContributors #63

Open
glyph opened this issue Nov 25, 2014 · 1 comment
Open

provide an API for ordering of IDescriptionContributors #63

glyph opened this issue Nov 25, 2014 · 1 comment

Comments

@glyph
Copy link
Member

glyph commented Nov 25, 2014

Description contributors typically have a place that they expect to appear in the description. Deterministic transcripts are one reason, but authors also probably have an order they'd like players to read in.

@glyph
Copy link
Member Author

glyph commented Jul 11, 2016

This issue could really use some motivating use-cases. Why do we want some description components to come before others? The solution proposed by #67 got me thinking about this, because it includes both a comesBefore and a comesAfter attribute for description contributors, which can result in paradoxical / unresolvable orderings.

So: why do we want description elements to appear in order? Some orderings are just for aesthetic purposes: for example, the exits list typically comes at the end of the description, and players will probably tend to scan for it there.

But in other cases, description contributors might elaborate on previous elements in the description. The most basic example of this would be:

He is wearing a green shirt.

His shirt is on fire.

Garments, specifically, also want to do the thing described here where the garments description contributor removes certain elements from the "carrying" list as it describes them as "worn".

We don't want to go with an interface to this that involves selecting an arbitrary number; that's why #67 does the thing that it does, which is that it attempts to expose an interface based on relative position with respect to existing description elements. It would be possible to ensure that the order was resolvable if two other invariants held:

  1. we support only one attribute, comesBefore or comesAfter
  2. setting these attributes is done at class-definition time so that they have to be defined in a specific order.

Unfortunately, we have one use-case for comesAfter - elaborating on an existing description element - and one case for comesBefore - pre-empting the description of another object by a different contributor by removing it from paths before it can get to it. So, at this point, this needs some further design work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant