Questions about NewValueHolder and Model

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