As a former and long smalltalker who learned MVC from the ParcPlace crowd…

I used to say things like this. M and V were always pretty unambiguous, but “controller” was kind of like “Christianity”, everyone talks like it’s a unifying thing, but then ends up having their very own thoughts about what exactly it is, and they’re wildly divergent.

One of the early ParcPlace engineers lamented that while MVC was cool, you always needed this thing at the top, where it all “came together” and the rules/distinctions got squishy. He called it the GluePuppy object. Every Ux kit I’ve played with over the years regardless of the currently in vogue lets-use-the-call-tree-to-mirror-the-view-tree, yesteryears MVVM, MVC, MVP, etc, always ends up with GluePuppy entities in them.

While on the subject, it would be remiss to not hat tip James Depseys MVC song at WWDC

https://youtu.be/kYJmTUPrVuI?feature=shared

“Mad props to the Smalltalk Crew” at 4:18, even though he’d just sung about a controller layer in cocoa that was what the dependency/events layers did in various smalltalks.

Yeah, in my experience, just MV is largely just fine.

I like the term "GluePuppy". It absolutely is a crucial part, or parts.

Basically, it defines the architecture of the system, pulls all the objects together and connects them to create a useful system.

It doesn't help that we don't have linguistic support for "glueing things together", we only have procedure calls. So that's one of the issues I am addressing with Objective-S, actual linguistic support for "glue". And yeah, please don't put the rules/distinctions over designing a clean system.

That was a thing I discovered only recently when working with two teams, one Android and one iOS: developers in general, and particularly good architects, want to build these uniformly recursively decomposed modules.

You can't do that with a good OO architecture, because you absolutely need the GluePuppy to tie things together. That one is different from the other modules. If you don't allow for a GluePuppy, but instead insist on uniform modules, you inescapably get procedural decomposition instead of OO decomposition. If you are in an OO language, that means singletons everywhere, because every module needs to know about its dependencies. And that gets you into a world of hurt when you want to do what OO is supposed to be good for, handle variation.

Embrace the GluePuppy! It loves you and wants to make your life simpler.

The "lets-use-the-call-tree-to-mirror-the-view-tree" fashion also has to do with this, IMHO, because our languages only have support for writing down procedures. So if you can get your view-tree expressed by the call-tree, you get to write it down directly in the code, rather than constructing it indirectly, with the view-tree being a hidden side effect.

That is a clear benefit, but the costs are pretty horrendous.

How about we extend our languages so that we can also write down those view hierarchies directly in the code, and at the same time using a format that can also be read/written as data (down LISPers, down)?

Controller seemed fairly straightforward to me initially, when I was first learning Smalltalk (ParcPlace), and I took my simple understanding on faith.

My programs were simple, so M was data, V was presentations of the data, C was interaction on the M and maybe V.

It only got confusing when I got more experience.

There’s also a difference between the code needed to create and set up the combination, as opposed to the code that executes based on events after things have been set up. The way MVC is generally presented, it is only about the event-time code, but in practice the set-up code and the event-time code are not independent and are usually combined within a single class or module.