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

[brett l. <bre...@gm...>]

On Wed, Sep 1, 2010 at 11:56 AM, Erik Vos <eri...@xs...> wrote:
> Stefan,
>
> Some comments:
>
>>I would even go one step further: The supposed difference between state and
>
> model classes is unnecessary and I would rename all state classes to model
> classes: Thus instead of IntegerState we would have IntegerModel and so on.
> If we still have different packages, I would separate GenericModels (as e.g.
>
> IntegerModel) from RailsModels (as BaseTokensModel).
>
> [EV] I think you forget that we have quite some ModelObjects that are not
> State objects, but only serve as Observables for the UI.
> Whether or not it is a good thing that these are not State objects is
> another matter - perhaps that needs to be reconsidered.
> But as long as this is the case, I would keep ModelObject and State
> separate, as these serve different (if often combined) purposes.
>

Post-merge, perhaps it makes sense to have certain Model objects have
an Observable property?

e.g. bool isObservable = True


Or, maybe it doesn't matter, and the UI simply uses the Model objects
that make sense, and doesn't use the ones it doesn't need and there's
really no difference between them at all. :-)

> (BTW It might be interesting to sort this out in more detail. For instance,
> I wonder why I ever have created both CashModel and MoneyModel, of which
> only the latter is a state object. All I remember is that I once thought to
> have very good reason for this difference, but it has slipped out of my
> mind.... Perhaps some further digging will reveal it).
>
>>I only differ in the implementation details:
> I would prefer to derive the specific models (as ArrayListState/Model
> IntegerState/Model) directly from ModelObject, as the GenericState/Model
> mechanism creates a new object for each change (move) of the model.
>
> [EV] That would be the case if always the superclass set() method is used,
> but that is of course not necessary. Subclasses can add delta methods (such
> as IntegerState.add() or ArrayListState.add()). We might even make
> subclasses smart enough to override set() to use delta actions (for
> instance, BooleanState would only create a new object if it is null).
>
> However, your point is well taken in that I now understand that we should
> not use State<Integer> to create state objects, but always use subclasses
> like IntegerState (extends State<Integer>).
> Even then I think we would still save code: (1) State and GenericState<>
> have merged, (2) less need for casting (e.g. no more booleanValue() etc.
> needed).
>
> But of course, if State<> would end up empty, or all its methods would be
> overridden anyway, there would be no need for it indeed. However, I would
> prefer to have that being the final outcome of a rationalization process
> rather than a starting point.
>
> I hope you understand that I'm not trying to force anything - this is just
> my view. If you want to go ahead with this your way - fine with me. In any
> case, later refactoring in either direction shouldn't be difficult.
>


If you want to do this before gaining complete consensus, create a
branch and develop your changes in the branch. That'll make comparison
easier and may help achieve consensus. :-)

> Erik.
>
>

---Brett