[Reality] A few thoughts on Action related matters

Jp Calderone reality@twistedmatrix.com
Thu, 4 Jul 2002 18:49:15 -0400


--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

  Almost there, I think.  So far things are looking good, there're just a
few things I've run into...

  Thing.locate() - This could probably use an extra parameter, 'interface'
(defaulting to None).  First thought was just to pass it through to
=2ElookAroundFor() which now also takes a parameter of the same name.  This
work, but gives what I think is an incorrect error message to the user
(Keeping in mind that .locate() raises CantFind() or Ambiguity() in error
conditions, which are reported to the player).  IMHO, the CantFind() case
needs to be broken into a case where truly nothing matches the given name
and the case where something(s) match, but none implement the given
interface; something that ends up yielding something to the effect of
"%(name) can't be used in that way."  I'm not sure if the .find() method
should do something like this as well, because I'm not entirely sure what
the intended uses of these two fairly similar methods are.

  DispatchingAction - (Note: I acknowledge in advance that this point is
extremely trivial) The three classes beyondspike derives from this are for
targetless actions ("say", "yodel", "clap"), targetted actions ("get",
"sit", "nibble"), and tool actions, which are basically two-target actions
("hit X with Y", etc).  The minor nit I have is with the default argument
ordering of ToolAction's getDispatchList().  The ordering (modulo an offset)
is "actor, target, tool" for two methods but "actor, tool, target" for the
third.  Since changing the order now will break at most two projects (and
only one - mine - if glyph hasn't written any code that uses this yet)
changing it now isn't a problem.

  As a learning exercise, I've implemented one of each of the existing types
of DispatchingActions.  Basic speech, whispering to a target, and a vending
machine.  So far the third has given me the only problems.  My vending
machines implement the IInsertTarget interface and my coins implement the
IInsertTool interface.  The vending machine, however, needs to know more
about the coin than what its interface provides, specifically its value.=20

Option the first: Add a value method to the insert interface (rejected,
stupid). =20

Option the second: Create a new interface, ICoin, and only allow
implementors of it into the vending machine.  Put the value method on this
interface.  This appears to work, but costs generality and, I think, leads
down the path to hordes of special cases and damages the chances of
initially unrelated things to interact in interesting ways.

Option the third: Remove the vending machine's ability to "cheat" and make
it identify what was inserted into it through general methods/attributes
that all Things implement.  Size, mass, spectral properties, Dingleforpen
index, etc.

I kind of prefer #3.  Deciding what properties are appropriate here is
important.  Some of them might be useful to add directly onto Reality's
Thing class, others might be game-specific enough that a subclass is
appropriate.  Alternatively, a simple interface for asking about an
arbitrary property might be preferable over adding accessors along the lines
of those that already exist.  =20

I can see the merits of the second option, but I doubt my ability to
properly design and implement a set of interfaces that both provides is
complex enough to be interesting but clean enough to be extensible and
understandable.  Option #3 appears to make this easier.

Thoughts?

--=20
 2:00am up 44 days, 2:44, 7 users, load average: 0.00, 0.01, 0.00

--SUOF0GtieIMvvwua
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9JNDpedcO2BJA+4YRAs3lAJ90V/Jf09CYpqGvfFRAfJg9wLxinACfQrzd
p2XVT8g8nX6jcBpp7Bajh+c=
=TTdU
-----END PGP SIGNATURE-----

--SUOF0GtieIMvvwua--