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

[Erik V. <eri...@xs...>]

 

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Thursday 02 September 2010 23:12
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Some (multi-)undo related bugs

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)

[EV] The current ModelObject was basically intended to provide for case B).
'Model' is used here in the very limited sense of a Rails-style Observable.
I conclude that you want to give it a more fundamental meaning - fine with
me if that clarifies matters.
The fact that State extends ModelObject is merely caused by Java's main
defect:
the lack of multiple inheritance. I consider State and
Model-in-the-sense-of-Observable
as independent types, but the problem was that some objects need to be both.


[EV] I'm not sure if using the term Model in this limited sense does any
right to its meaning in the MV(C) pattern sense. Perhaps ModelObject is just
a bad name. I'm not well versed in MVC theory, to me it's all a matter of
practical solutions to actual needs.

[EV] What this all means for which way to go (if any), I don't know. If you
know ways to give these concepts a better foundation, please go ahead, as
long as it simplifies, not complicates the structure (for the sake of some
theory). I have seen to much unwieldy Java code to believe that following
preconceived frameworks tend to yield good results.

>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

----------------------------------------------------------------------------
--
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