Keith Hodges wrote:
> Personally I have never got on with morphic and would much rather see 
> something elegant in its place like Model-View-Presenter as used 
> superlatively in Dolphin.

[... snip ...]

> Surely a UI framework could benefit significantly from traits and so it 
> would be in their interest to move to 3.9?

It's kinda funny to see the two statements in the same message and I 
just can't withstand a little rant. Hope you don't mind ;-)

To me, Morphic is to MVC as traits are to classes. What I mean by this 
is that in MVC you have factored the roles into individual entities with 
well-defined individual responsibilities. They can be plugged together 
to enable a variety of interesting dynamic behavior. In Morphic, you 
have many roles in the same object which means overlapping 
responsibilities, less clarity and pluggability.

With traits, you use a similar approach to Morphic only on the 
meta-level, e.g., instead of composing concrete ui behavior in a single 
entity (Morph) you compose abstract trait behavior into a single entity 
(Class). From what I've seen so far, the results seem shockingly 
similar. Less clarity than when you have individually factored entities 
(classes), more unforeseen interaction inside the entity where you 
combine the different roles into, conflicting meanings which require 
renames and introduce more complexity (and confusion and conflicted 
meaning).

Another way to look at it is this: If you like MVC then think about what 
it would mean if you would create Morphic by combining models and views 
using traits. Would you think that the result is superior to MVC? 
Personally, I don't think so which is why there is a clear separation 
between the two in Tweak (in MVC terms only between model and view but 
this seems to be the more relevant distinction).

There are of course some situations where due to technical limitations 
it is not feasible to use individual entities (objects) to model a 
problem. In these situations a formal mechanism like traits is of course 
vastly advantageous to an ad-hoc mechanism like copying all the code 
manually between two places. But that doesn't mean it's the superior 
solution in general.

Here is another example: Most of the graphical attributes in Tweak are 
grouped into so-called "costume aspects". Those are individual objects 
that simply interact with a Tweak costume to model a certain role (like 
the costume's fill, its border, its text etc). These could have been 
modeled as traits by simply flattening the classes into the costume's 
namespace but making them individual entities makes it a lot simpler to 
deal with the interactions (besides, it saves space, allows controlled 
exposure of properties etc).

For example, I can send the message #bounds to the costume and get the 
composite bounds for the entire costume or I can send the message 
#bounds to the text aspect and get only the text bounds. It is always 
clear what I mean since I have to specify either "costume bounds" or 
"costume text bounds" and it never changes, neither in the aspect nor 
the costume. Compare this to a traits solution where I'd have to rename 
one of the two. Which one is clearer? The one where I say "bounds" when 
I implement a trait and "textBounds" when I use it? Where "show me the 
senders of #textBounds" finds the senders in the composition but not in 
the trait? Or where "senders of bounds" also lists all the senders of 
#textBounds since they were once called #bounds? I think the answer is 
clear.

[BTW, I just deleted a whole paragraph with another rant about things I 
think we'll see as a result of applying traits on scale but since nobody 
has used traits yet for anything real that rant just seemed a little bit 
too presumptuous. I think I'll just wait with this rant up until someone 
does something real so that I can point to the issues in context. And 
I'd *love* to see someone built a UI framework based on traits to 
illustrate some of these -in my opinion unavoidable- issues]

Bottom line: There are reasons to use traits in lack of alternatives, 
but if I can avoid it by using self-contained entities (objects) I'd 
rather not.

Cheers,
   - Andreas