[messages] [Developers] Re: [Developers] Vassal code maintainability
mkiefte at dal.ca
Fri Jul 30 12:26:33 MST 2010
> To be clear, what I'm suggesting is to remove keyEvent() from Decorator
> and instead just have myKeyEvent() on the pieces. Centralizing how key
> events are issued to traits in a single place will give you two
> benefits. First it will be clear what the visiting algorithm is (rather
> than needing to go into every trait to find out) but secondly, and more
> importantly, it will force the visiting algorithm to be consistent. I'm
> talking about separating concerns. Have the trait only be concerned
> with the action it needs to execute. Have the trait visitor be
> concerned with stuff like what order traits should be visited in under
> what circumstances, when one trait should block another trait etc. This
> would not only make existing behaviour more consistent, it would force
> future behaviour to be consistent too.
You'd be giving up a significant amount of power in doing that. Right now,
an outer trait can hijack the behaviour of an inner piece. I agree that,
from the point of view of VASSAL itself, it makes it confusing. However,
from the point of view of someone who makes custom VASSAL classes, it means
you can do some very powerful things. In addition, you have to realise that
there are many modules that you will break because they use custom classes.
While we can't be responsible for each and every one of those, you will
break a large number if you do what you propose.
The current model is unpleasant, but because it does hold some virtues, it
would be very difficult to overhaul. Even doing something like changing the
way triggers work would be disastrous.
myKeyEvent() does what you say. However, I would be loathe to get rid of
keyEvent(). It's actually come in handy.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the messages