[Reality] Wearable computing

[Glyph Lefkowitz]

----Security_Multipart(Wed_Sep_18_03:09:30_2002_519)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


On Tue, 17 Sep 2002 15:35:23 -0400, Jp Calderone <exarkun@meson.dyndns.org> wrote:
>   I'm trying to wrap my head around the pragmatic differences between
> inheritance and adapters, and not getting very far.  Wearable computing
> seems like a good example to play with so below I'm going to try to outline
> what is necessary for it, and then someone can tell me what's up.

OK.  It seems to me that there are 3 things you could mean by "wearable
computing", from an infrastructural standpoint.

    * You have a computer which you want to attach a strap to and wear. (A
      computer you want to make wearable.)

    * You have a shirt which you want to weave a computer into. (A garment that
      you want to make computable.)

    * You have an inert frob which you want to make into a computer-shirt.  (A
      random object you want to make both computable and wearable.)

> A wearable computer must able to be treated as an article of clothing.
> Wear/Unwear, track its own state (who is wearing it, where it is legal for it
> to be worn, etc).

Okay, yes.

> It must also be able to be treated as a computer.  Turned on/off,
> "interfaced" with (typed on, spoken to, etc) and track its own state (what
> does it know, how much power does it have left, who can use it, etc).

Yes, and I think we're agreeing that these should be separate responsibilities.

> As it stands, Clothing is a subclass of thing.Thing, which means it can do
> all its own state tracking, and __implements__ the appropriate interfaces to
> be interacted with.  If the 'computer' half of things, let's call it
> "Electronic" for now, is also a subclass of thing.Thing, we have the usually
> MI problems (hard to do initialisation properly, etc), but it can keep track
> of its own state.  If, on the other hand, Electronic is an Adapter, it can be
> registered for whatever Clothing subclass you want and things will probably
> work ok (if I understand correctly).

Yeah.  And neither Electronic nor Thing really needs to override any methods of
Thing or change its behavior.

> With cooperative method invocation (super(), requiring 2.2), the
> initialisation problems can probably be worked around.  But if this is
> indesirable (Inheritance is bad, right? :P), then clearly there's an
> asymmetry here.

Yep... sounds like you're right, and I made a mistake.  However, there are a
couple of reasons I did it that way.  First of all, there's history; I wanted
to make the upgrade from current stuff that was already Clothing less jarring.
This is clearly not an overriding motivation, but it didn't seem at the time
like there was a really good reason to make it just be an Adapter.

> Why does Clothing get to be a thing.Thing subclass and everything else that
> wants to play with it have to be an adapter?

The other idea was that Clothing actually is special because it interacts more
directly with containment.  It really _shouldn't_ be 'more special' though.

> Worse, what if two other things that want to play with it then also want to
> play with each other, in its absense?  Then there's no thing.Thing subclass,
> so something new must be created.  The way I see it, I think Clothing should
> become an adapter, along with pretty much everything else that subclasses
> thing.Thing that's now in the Reality "stdlib".

Okay.  This is reasonable, and I think that it will go a long way towards
making Reality a little more world-representation-agnostic, which would be
*very* good.

> Sound reasonable, or have I just missed something complete? :) I'll hold off
> on any more mods to Reality until I grok this point, because I'm pretty sure
> I'll be writing broken code until then.

except...

So the problem is, if *everything* is an Adapter, then it becomes very
difficult to ask the question "What is this?".  Thing becomes relegated to
*only* managing containment.  This isn't necessarily a bad thing, but then we
will need some kind of categorization system outside of inheritance.

For example, Clothing is Portable.  It is intrinsic in the notion of being
wearable that you can be picked up, put down, put in boxes, etc.  I suppose
this means that the Clothing adapter can inherit from Portable, but that smells
wrong to me.  Then you run into the same problem -- what if Electronic wants to
inherit from Portable too?  All of a sudden you can't have two Item behaviors
on the same object.

I think this means that we should have "category objects" which specify
factories and invariants for certain constellations of functionality that can
be associated with Things, and perhaps for Things themselves, in order that we
don't get nonsensible (incompatible) combinations of stuff.  'Electronic +
Portable + Clothing = YES' but 'Clothing + Landscape + Explosive = NO'.  This
may also imply that some adapters are intrinsic but others are extrinsic.  (I
*am* a flute, but I just *happen* to be enchanted at the moment.)

It's also starting to seem like each Adapter should be managing one description
element on its object, at least abstractly.  Electronic objects are going to
want to mention that they're on/off.  Wearer is going to want to mention that
certain clothing is worn / not worn.

So to bring this back to something a little more concrete: what should the
experience of _creating_ a wearable computer be like for an author in the
world?  For a developer using this API for character creation?  I am not quite
sure right now, but I'll think about it.

-- 
 |    <`'>    |  Glyph Lefkowitz: Traveling Sorcerer   |
 |   < _/ >   |  Lead Developer,  the Twisted project  |
 |  < ___/ >  |      http://www.twistedmatrix.com      |

----Security_Multipart(Wed_Sep_18_03:09:30_2002_519)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

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

iD8DBQA9iDTAvVGR4uSOE2wRAqr9AJwLNTQUpMgwGtX1bcrNdxARl4S67gCfYXns
Fuwge854WlYkO1h4fF3YKb8=
=51ol
-----END PGP SIGNATURE-----

----Security_Multipart(Wed_Sep_18_03:09:30_2002_519)----