Re: [Tads3] knowledge / 'seen' / npc knowledge base

[Jesse Welton <jwelton@xxxxxxxxxxxxxxxxxxxxxxxxxx>]

Søren J. Løvborg wrote:
> 
> > Agreed - that's the usage I had in mind.  I'll think about adding it, 
> > although I'm not sure it would really be justified given the light use it 
> > would probably see (even counting the space savings and improved 
> > abstraction).  Any opinions on the value of adding this? - in particular, 
> > does anyone think they'd have a lot of use for it?
> 
> I don't think it's worth adding an new metaclass just to save, what,
> 7 bytes per entry?

The primary reason for it would be that a Set is a better model of a
set than a HashTable is.  A marginal space savings is just a minor
side-benefit.  The question is, are sets used often enough (or would
they be, if available)?  That, I don't know, but they are certainly a
useful abstraction for many purposes in general programming.

> >   addElement(x)
> >   removeElement(x)
> 
> However, if we decide to add one anyway, be sure to add a "setElement"
> method  (or something), as in:
> 
> setKnownBy(actor, val)
> {
>     actor.knowledgeTable.setElement(self, val);
> }
> 
> instead of forcing a
> 
> setKnownBy(actor, val)
> {
>     if (val) actor.knowledgeTable.addElement(self);
>     else actor.knowledgeTable.removeElement(self);
> }

Wow, I definitely disagree.  This is treating a Set like a key->value
mapping, which it is not.  If you're using a knowledgeSet instead of a
knowledgeTable, the latter code is far clearer.  Of course, it should
really be moved to the actor, which would make it more readable, and
better encapsulation as well.  Better yet, since the code calling this
method will undoubtedly know the value of val, simply use separate
setKnown(obj) and setUnknown(obj) methods.

-Jesse