[Reality] A state of near-permanent confusion

[Christopher Armstrong]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig81C07AF2070DF39B19A6DCB4
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Exarkun and I have been doing a bunch of thinking and talking and some 
tinkering with the Imagination codebase. We found out that we're very 
confused :-) There's a definite deficiency in the "criterion" system; we 
don't know how Events will fit into all of this, and we are generally 
confused about find and more.


== Criterion problem ==

Currently we have a criterion(implementor) callable that we can pass to 
collect(IWhatever, criterion, radius) to choose particular implementors, 
but that's not good enough. For example: Our player says "go east". We 
need to restrict our search to IWalkTargets that are physically east of 
the player. The actual IWalkTarget implementor is the *room* that we end 
up in, not the *door* that we're going through. So, if we have something 
like this:

      _____
     |     |
     |__.__|
        #####
      ____  #
     |    | #
     |    .##
     |____|


And our criterion says

   def crit(o):
     o.isEastOf(actor)

then it will not do the right thing: the room (IWalkTarget implementor) 
is actually north of the actor, while the door is east (and "go east" 
should definitely refer to the door, not the room).

Then again, maybe we don't really want to have this kind of mapping? If 
we don't, then there's another use case that's basically equivalent: we 
want to say "enter blue door"; we'll grep for IWalkTargets and we need 
to restrict them to those knownAs("blue door"). Thus we need access to 
the finder, not just the implementor.

== Exarkun's solution ==

So... exarkun tinkered around and changed criterion's signature to 
(finder, implementor) instead of just (implementor). That satisfies the 
above use-cases, but I'm still wondering if it's all we need: Maybe we 
will need to do something with every find-implementor on the way to an 
interface-implementor? I haven't thought of any use cases for that, though.

-- Some rambling --

Hmm... Ok, here's one :-) (but perhaps it would ideally be implemented 
another way). "cover eyes; drop flash-bomb": This action causes a 
blinding light to travel outward from the point of impact. In a map like 
(man, I need to figure out that box-drawing stuff for emacs):

   F-E
     |
   A-B-C
     |
     D-G

, where the bomb goes off in room B, we want the light to spread outward 
to IVision...Actors, I guess? :-) and call their .blind() method. The 
light should travel to A, B, C, D, and E, but not F or G (assuming they 
all have open doors between them). We need to be able to ensure that we 
only go through rooms that are in a straight line from the asker. So, 
here are ideas for facilitating this:

  * Pass _all_ the finders on the way to the current implementor to the
    criterion function, and have the criterion-function check to make
    sure they're all in a straight line from the asker. This seems
    uber-lame.
  * Have a separate criterion function for "more", so we restrict more's
    output to only those in a straight line from the asker...?
  * uh. I thought I had a third one, but I can't remember it.


== My bizarre idea ==

Before exarkun's idea of passing the finder, I had a different one that 
he didn't like that much. He pretty much convinced me it was wrong. They 
both facilitate our "name" and "direction" use-cases, but exarkun's 
seems to separate the knowledge required better.

Anyway, it would be another argument to collect, criteriaDict (surely 
there could be a better name) that would have things like {IDirection: 
ambulation.EAST} and {IKnownAs: "blue door"}. Then our `find' 
implementations would look at this dict and would do things like 
IKnownAs(self) == criteriaDict[IKnownAs] or directionFromTo(asker, self) 
== criteriaDict[IDirection]. Glyph thought this idea was "interesting", 
but then lost interest ;-)

This solves the problem in a different way: The responsibility of these 
operations becomes that of the find-implementor rather than the 
criterion-function-creator. I think that exarkun's idea is probably the 
way it should be done, and I only mention mine here for the record and 
to perhaps spark new ideas.

== Other confusion ==

That's the biggest issue, but as I said above, we're still confused 
about how Events will work and when to implement find vs more. e.g., why 
does 'more' get passed the interface and criterion? The existing, 
trivial implementation of it ignores them completely: are there any use 
cases that access to this information was meant to facilitate?

Ok. I can't think of anything else to be confused about, for now.

-- 
  Twisted | Christopher Armstrong: International Man of Twistery
   Radix  |          Release Manager,  Twisted Project
---------+           http://radix.twistedmatrix.com/

--------------enig81C07AF2070DF39B19A6DCB4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAHT44Np279O1/OG4RAtg5AJsFx7Syi+Bom4/SZPlufbeOlFYefgCePoeT
Z2e2FwuPy5DGoNQiWNj6g90=
=EZJc
-----END PGP SIGNATURE-----

--------------enig81C07AF2070DF39B19A6DCB4--