[Divunal-devel] Re: [Reality] Re: darkness

[Glyph Lefkowitz]

This works, except for the fact that it doesn't :-)

Explanation follows.

On Sun, 22 Aug 1999, James Knight wrote:

> At 6:27 PM -0400 8/22/99, Glyph Lefkowitz wrote:
> 
> Nononono...those should really be properties...not special things like they
> are now. Then the 'to' versions already exist, and everything is all happy.
> Also they will inherit, and do all those nice things properties do.
> However, there is one real bug with dynamic properties combined with
> Property Change Listeners (which don't exist yet, but we should add)...that
> is that there's no real good way to tell if a dynamicproperty has changed.
> This is basically a concrete limitation, in that there is no way to work
> around it in a general way. However, for specific instances, it is workable.

If these properties inherit, then you need to register property change
listeners for the full property table of the superclass for each subclass
(addPropertyChangeListener("*",theChangeListener)?) EXCEPT where the
subclass has an overriding property, in which case this is ignored.

Doesn't that sound like a big performance hit for a really negligible
gain?

> Lets take for example the mirror in the Divunal demo area. That has a
> dynamicproperty for its description that takes the description of the
> Player looking at it, and uses that in its string. Now, the mirror should
> really change when you change your description. To do this, it needs to be
> registered as a Property Change Listener on the Player's description, and
> if that changes, trigger a property change event on _it's_ description [to
> that player].

Except for the fact that it's using fullyDescribeTo, which isn't the
description -- it's the description+*elements*.  Does that mean that
descriptors are now going to be dynamic too?  Should these be shuffled
into the main property table?  

> The same kinda thing might be workable for dark rooms too, although it is a
> significantly more complex example, and I haven't fully thought it out yet.
> However, given that darkness is a fairly general thing, and in fact, ALL
> rooms should be "Class_Dark Room" really (with the darkness set to light),
> it might be better to rethink doing it as dynamicproperties for description
> and stuff.

Darkness is certainly not a general thing.  Most places aren't dark.  The
outdoors, for example, can't be dark, although it can be night ... in the
same way that all rooms should not be "class_submersed room" with most
places set to a water-level of 0...

Since the only property change listeners we'd ever need to add have to do
with the way things look (name, description, etc) it seems to me that we
should special-case those properties and then just make sure the
description gets refreshed... this wouldn't make darkness cleaner, really,
it would just make it more complicated (since the property change
listeners would have to be wired together in much the same way the current
eventhandlers are)

Considering that darkness actually *does* work now, this isn't necessary
... as a matter of fact, it seems to complicate things more for me...
although I think my opinion would be greatly swayed if somebody could
think darkness *all* the way through.

Also, let's PLEASE keep our maillists straight.  TR does not have
darkness as a feature, and since those people can't look at the code we're
discussing, I think we'd best keep the discussion here.

--glyph