David C. Ullrich <[EMAIL PROTECTED]> wrote: > Matthew Woodcraft <[EMAIL PROTECTED]> wrote: >> For example, if you were writing the 'logic' for a chess program you >> might choose a way of modelling the board that can't represent a >> position with more than one black king. And then when you got round >> to doing the GUI you might find out that your users would like to be >> able to have this temporarily when setting up a position.
> What you say may be true, but this doesn't seem to me like a good > example. Not that I see _why_ the player would want to have two kings > temporarily, but if so I wouldn't have the view report this state to > the model, I'd have the view wait until the player had decided on the > final configuration betore saying anything to the model. The model > should only deal with legal positions. Then you end up implementing a second model of the board state in the UI layer. And if it turns out that you want to support things like 'save current position' and 'clone current position to a new window' during setup, you might well find yourself putting so much logic in the UI layer that some of what you already wrote in the 'logic' layer ends up unused. As for why you might want illegal positions during setup, imagine a UI where you can click on a square repeatedly and it cycles through the possible pieces (dunno whether this would be good in practice, but I do know that guessing whether a UI is good without trying it is rather unreliable). -M- -- http://mail.python.org/mailman/listinfo/python-list
