At 12:38 -0800 25/01/02, Irv Kalb wrote: >Carol, et al, > >While these solutions do work, they are not very clear about what is >really going on. I've always felt that it is much more important to >write code that can be read easily both by yourself and by others >that may follow, than to try to write an obscure single line that >works, but is unreadable. It is also a good goal to write code that >is generic, that is, it will work in many cases.
Couldn't agree more... would've never used such a single line beast myself ;-) I also store the stateMembers in a beginSprite handler, usually in one property list, but while the member-naming scheme may be "pedadagogic" and communicative, I use the sequence of adjacent members to signify their state. So the member actually attached to the button is the "default" state, and the next is "down", or whatever and so forth. This can even be quite self-documenting: tNummbr = pSprite.member.number repeat with tState in [#up, #down, #left, #right, #exploding] pStateMemberPList[tState] = member tNummbr tNummbr = tNummbr + 1 end repeat The later on: pSprite.member = pStateMemberPList[pCurrentState] This suits my style better than the rigorous naming. Decide on your button-conventions early, and be consistent. Jakob [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
