[messages] [Developers] Re: [Developers] Re: [Developers] Vassal code mai
ken.stevens at sympatico.ca
Fri Jul 30 12:50:24 MST 2010
> You'd be giving up a significant amount of power in doing that. Right
> an outer trait can hijack the behaviour of an inner piece. I agree
> from the point of view of VASSAL itself, it makes it confusing.
> from the point of view of someone who makes custom VASSAL classes, it
> 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
> While we can't be responsible for each and every one of those, you
> break a large number if you do what you propose.
I didn't realize that players made their own custom traits. Well you're
stuck with that API then. That's unfortunate.
There's a software design theory that says that programming structures
should mirror user-interface structures. So if users think of a list of
traits as a list, then they should be implemented as a list.
In that other thread, viewtopic.php?f=5&t=3258, I think a big part of
the reason it took 20 posts to get the answer to, what I felt was a
relatively straightforward question, is that there is a disconnect
between how the user interacts with traits and how the java code
implements them. If dispatching keystrokes to traits were implemented
using a visitor pattern, then I bet instead of 20 posts, it would have
only taken 2 posts to find the answer to my question, because all you'd
need to do is read the answer straight off of the trait walker method.
As it stands now, to get the answer, you need to go into each and every
trait to see how they interact with each and every other trait. That's
But you're right. If there's custom code out there that is using this
(unintuitive) API, then we're stuck with it. I know it makes perfect
sense to the VASSAL engine coders. But to the average module designer,
Read this topic online here:
More information about the messages