Hi everyone! I was trying to find out how to propagate changes through widgets in the Spec UI framework, and so far it seems to me that using NewValueHolder objects is the most proper way right now. Am I wrong? However I have some questions regarding this class: (BTW I am using a Pharo 7 image) First, you may notice that NewValueHolder extends the Model class, whose class comment simply says "Provides optimized model support". The first thing I thought coming from a non-Smalltalk background was like "What is that supposed to mean?". Then I tried to make sense of it, but you know, this has been hard because Model has a lot of methods that aren't too related IMHO. For instance let's take all the methods under the 'stepping' and 'stepping-window' protocols ...what are they intended to do? After doing some research I think they are some kind of mechanism from the Morphic framework to setup actions that will be performed periodically, probably for supporting animations or something, but what does this have to do with being a Model anyway? All of this has been pretty confusing, but I think I've understood it better after reading this post about Smalltalk MVC: http://peter.michaux.ca/articles/smalltalk-mvc-translated-to-javascript . I know this may be a bit obvious for veteran Smalltalkers, but now it has become clearer to me that this Model class is the M of the MVC framework that was used in ye olden days to build Smalltalk UIs. Which is weird because as far as I know MVC doesn't exist in Pharo. So I asked myself: "Shouldn't this be killed? Why is it kept? (at least it should be cleaned up I think)". And after searching the references and senders of the methods I think it mostly comes down to Morphs. Is it feasible to clean this up? I think all of this should be explicitely documented at least, you know, all this Model API. Currently it's too implicit, not friendly for newcomers and too mixed up with random Morphic stuff (which should be dying soon anyway). Some other thing that bothers me it's that that most of the methods in Model are defined in Object too. I understand that that was made in the original MVC to have the ability to use anything as a Model, but I don't think that's necessarily the best option. It would be cleaner perhaps to have an asModel message which creates a ProxyModel object which implements all the Model API methods and then proxies the rest to the underlying instance; or maybe a more pragmatic approach would be like moving all these Model methods in object to an extension protocol; or ...hey, it's 2018! Today we have traits, we could create a Trait with all those methods and then just let the current Model class use it. That's are my thoughts about the Model class. Now I'm not an expert, so they should be taken with a grain of salt ;) Coming back to the NewValueHolder, other two issues came to my mind: - What's the deal with the old ValueHolder class? Apparently it's not used anywhere. I think it should be removed, and NewValueHolder should be renamed to ValueHolder. - Some messages of NewValueHolder are also in the Model class in the 'announcing' protocol... What's the point of this polymorphism? This is not like the classical Model API at all, which uses the dependents and updating protocols. All these methods under the 'announcing' protocol use a totally unrelated way of propagating changes. This breaks SRP, shouldn't we have instead like a NewModel class which uses this new Announcement-based mechanism for propagating changes and don't conflate the two things? - In the same fashion, I don't think there isn't any good reason for having the NewValueHolder as a Model subclass; at least the Model that implements the behavior from the old MVC framework. For the record in my image I've done 'Object subclass: #NewValueHolder (...)', copied all the announcing methods to NewValueHolder and added an announcer instance variable and it's going fine so far, but that might be because all Objects can be used as models in the MVC sense. Anyway, after some use 'Object classVariableNamed: #DependentsFields' still prints "#DependentsFields->a WeakIdentityKeyDictionary()" :P I think that's it, or maybe I forgot something I don't know haha -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html