From: Stefan F. <ste...@we...> - 2010-09-01 21:41:54
|
Brett & Erik: thanks for your feedback. Some more comments below. I do not think that an (extra) branch is required for those changes now. As long as there is no agreement here, I will work on other issues first, and even if there would be a consensus, it is not that high on my priority list now. Stefan > > > > [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. :-) I agree with Brett's last sentence: From my understanding (now) is that there is no inherent difference between Model and State objects, other than naming. All of them are changed (directly or indirectly via other states) by moves and have the ability to update observables. The latter usually UI elements, but also other states. I do not see any own property or behavior that is specific to the State classes. > 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. :-) > |