Concurrent states in Ember


#1

The saga (Why there is no concurrency and history mechanism implemented in Ember.Router?) continues.


#2

Hehe… so yeah, I hope by now you’ve looked at @nathanhammond 's presentation from Ember Conf? :smile:

If not, it’s here: https://www.youtube.com/watch?v=iFBOYMxDl40 and also on confreaks website.

Anyway, I find that it might be interesting to think about DCI from this perspective, too… here’s a discussion on it if you’re not overly familiar with it:


#3

Yeah, I’ve watched it…once :slight_smile: I need to watch it more times to see how could I describe my problem with a flow. Probably it’s a shame but I haven’t heard of DCI yet but this line really aroused my interest: “how it can produce source code that maps directly from end user mental models, making it easier to understand and evolve.”


#4

Yeah! Exactly. That’s the main win of it, I think. You want to capture the end user mental model (DCI talks about this a lot) in the source code… because that’s how the obejcts are actually being used. Baking a state machine of how your code interacts and reacts to user input with whatever objects are presented.

Yeah I got quite into it just before I discovered Ember…tho hadn’t got a chance to use it yet… and Ember doesn’t really directly address this, but the work that @nathanhammond is doing seems to be connected here - it involves reifying the interactions (the I in DCI) into first-class citizens as wrappers (acting in a particular context, the C in DCI) around the Data of the application… it works in tandem with MVC…

Effectively, @nathanhammond 's flows are Trygve’s interactions… behaviours of objects interacting in contexts… focussing on when they’re alive, instantiated and in use interacting with other objects, rather than allow this stuff to exist *across the entire application, after specifying the objects according to some “type” which is what classes ordinarily capture.

I’m incredibly interested in this, because it’s more “true” than just MVC alone… it forces and helps the programmer to think fo how their objects are actually being used in the systems they’re building and encourages true reuse because if we can reason about objects’ interactions, then we’re able to reuse that code directly if it’s needed in a different application or context. Massive wins.