Re: [Rails-devel] Some (multi-)undo related bugs

[Stefan F. <ste...@we...>]

Brett & Erik:
Depending on the interpretation of model and state (general idea, pattern 
context, Rails context) I can agree/disagree with all your statements below.

Example: If model is simply the whole set of data/structure of an 18xx game, 
and if state is defined as something that change its structure /behavior 
/properties at runtime, then I disagree (think definition of tracks on tiles).
If we define model as all classes that inherit ModelObject and state as above, 
than I easily agree.   

So I try to clearly identify my interpretation my take simply is: Parts of the 
(game) model, which change their state (as defined above) directly/indirectly, 
extend ModelObject. There is no substantial difference, if the UI subscribe to 
the object or if only other part of the (game) model.

Thus I suggest do derive all three cases below from ModelObject:
A) First-class model objects (have state of its own, update UI directly)
B) Derived model objects (derive their state from A) or C) type objects, but 
update UI directly)
C) State objects  (have state of its own, but do not update UI directly)

From my point of view the difference between A and C is irrelevant on the 
model (MVC context here) level, as the model should not care which elements 
the UI/view subscribes.

The difference between B and C might be somehow more 
relevant, especially if the only composite information for specific UI 
elements. Then it would make sense to move those into a controller layer, but 
they could still follow the ModelObject observer pattern. 

Another suggestion is those objects that have a state of their owns (type A 
and C thus get changed by Moves) implement a Moveable interface to identify 
those.  

Stefan

On Thursday, September 02, 2010 10:19:35 pm brett lentz wrote:
> On Thu, Sep 2, 2010 at 11:46 AM, Erik Vos <eri...@xs...> wrote:
> > Turn-based boardgames are effectively state machines.  I'm not sure I
> > can think of a model object that should be stateless.
> > 
> > Certain parts of the view (in an MVC world) can and should be
> > stateless, but the model *is* the state of the application (read:
> > game).
> > 
> > [EV] Of course there is always some form of state behind a model, but
> > often it is not a single state. For instance, the views that give you a
> > list of available trains, or the player worth, or a share percentage,
> > have models that depend on some calculated value, which is not an
> > independent state itself.
> 
> Correct. This is where MVC tends to be an improvement to just an MV
> design. Typically, the controller possesses the "business rules" that
> derives those calculated values from the model.
> 
> Originally, we started with a Model-View design. It's probably time to
> work on cleaning up the distinction between Model and Controller, and
> making that distinction to help clarify which is which.
> 
> > Erik.
> 
> ---Brett.
> 
> ---------------------------------------------------------------------------
> --- This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel