[messages] [Developers] Re: [Developers] Re: question about delete and or

Michael Kiefte mkiefte at dal.ca
Thu Jul 29 10:03:48 MST 2010


I think it's extremely dangerous to change things.  It may be possible to
deprecate inconsistent features.

It mostly makes sense.

However, there is a feature that I've used that only sort of works that
doesn't make a whole lot of sense.  If two traits respond to the same key
event, they will both respond, but some traits do not check the inner trait
to see if anything else will respond.  And I don't mean the "restrict
commands" trait which is obvious.  I'll see if I can find the one I mean --
i.e., it will respond to the keystroke, but nothing above it will.  That
drives me nuts.

Another inconsistent feature is traits that check for properties.  Some
check for property names starting from
getOutermost(this).getProperty(propName).  Others only check property names
starting from getInner().getProperty(propName).  That also drives me nuts.

And kids that walk on my lawn.  They drive me nuts too.

- M.

On 29 July 2010 13:32, fil512 <ken.stevens at sympatico.ca> wrote:

>
> "uckelman" wrote:
>
>> Thus spake fil512:
>> The more discussions I see of the way that traits work, the more I
>> think
>> that we need to overhaul it to make it more consistent...
>>
>>
>
> I agree with you that consistency is the best route whenever possible.
>
> However, there are probably good, practical reasons why VASSAL has made
> exceptions to consistent trait order execution.  But if you are going to
> make exceptions, then you really need to write down the rules for people
> so we know how it works.  Otherwise module designers will code via trial
> and error, and guesswork which will result in them feeling frustrated
> and it will also result in convoluted modules.  I'm really happy to hear
> that someone is working on updating the Reference Manual.  That's hard
> work, but the benefits to the community will be enormous.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vassalengine.org/pipermail/messages/attachments/20100729/5b5bf55d/attachment.html>


More information about the messages mailing list