Darkness objections leak out to where they don't make sense

[exarkun]

If you are near enough a dark place and an action you take fails because obtain doesn't find anything then you'll get a reason that relates to darkness that doesn't make sense. If you modify example_game so that "The Middle" is dark then you can produce this:

> look
[ The Beginning ]
( north )

> look north
[ Blackness ]
You cannot see anything because it is very dark.

> look south
You don't see that.
> go south
It's too dark to see.

[exarkun]

So what happens is that there is no "south" in the current location. Idea.obtain produces neither results nor objections related to paths terminating in "The Beginning" because Named doesn't let anything through. obtain progresses to "The Middle" via the Containment.links result that respects the "north" Exit. There are some paths through "The Middle" to other ideas - eg the "south" Exit, the squeaker, etc. Once "The Middle" is dark, though, it has LocationLighting as an ILocationLinkAnnotator. "The Middle"'s Thing.annotationsFor loads its LocationLighting. So every link in paths through "The Middle" has LocationLighting's annotation (_PossiblyDark) applied to it. CanSee then uses _PossiblyDark to create an objection to these paths. When Idea.obtain doesn't give Thing.obtainOrReportWhyNot any results it looks at objections and picks one and all it has to pick from is the _PossiblyDark objection.

So the action is reported as failing because "It's too dark to see."

In some sense, this isn't wrong. It is too dark to see in "The Middle" and maybe there is a "south" there (there is, though it doesn't matter, you have the same problem with "go west" or "take spam" or whatever) but it is too dark to see it.

But what it isn't is "simplest" or "least surprising". Yes, there's a dark room nearby where we can't see if there's a "south" or not. However there's also a light room that we're currently in and we can't see any "south" there. This nearer failure is the one that is more relevant. It would be cool if we could use path length associated with an objection to select the one to report but:

• objections aren't associated with paths in the current implementation and the current interfaces don't allow such an association to be made
• there is no path for the "south" that doesn't exist in "The Beginning" because ... it doesn't exist. Only things that exist can have paths.

I can perhaps imagine some transformation to the interface so that results and objections are associated with each other. That might be even more than we need though. If we just want to use the shortest path's objection, it would be enough to keep objections in order then do a breadth first traversal of the graph. The first objection should be associated with the shortest path (or at least tied for shortest). This doesn't deal with the problem that there is no path for "south" though.

I can also imagine adding another linker which gives you things like "north", "south", etc. Notionally, these things do always exist. There may be no exit to the "south" but "south" exists regardless. Then you could have a path there but either:

• some annotation on the path could produce an objection and maybe this objection would be the one reported when the action fails
• the path could be allowed and terminate in an actual IExit implementation - but one that denies traversal (raise an ActionFailed from traverse)

I don't have a clear sense of whether either of these really makes sense, or which would be preferred though.