DCI and Time

[Matthew Browne]

Picking up from this thread...

The relationship between DCI and time is a large topic that could involve many years of research. But I am not an academic and one has to start somewhere, so I have been searching around the web to see what I might learn from other approaches.

One of the more interesting things I found was an article by Tom Brus entitled "Beauty and Code" from the book The Beauty of Functional Code: Essays Dedicated to Rinus Plasmeijer on the Occasion of His 61st Birthday (link). (I was just reading some excerpts on Google Books.) Quote:

Conveying meaning is the essence and beauty of code.

One of the essential spoilers of understandable and clear code is the inevitable time sequential specification in imperative languages. It is one of those little critters in programming we could happily do without. It always spoils things. There is always a sequence of events that you did not take into account. In catering for these rare sequences you add code and then more code, you add complexity and make it less understandable, less beautiful, often even ugly. An additional problem with sequential specifications in programming languages is that it is only essential at some points. At many points in your program it is not important and therefore an over specification. The main frustration comes from the fact that it can not be specified where sequential execution is essential and where it is not. It is then very hard, if not impossible, for humans as well as computers to separate the two. We need programming languages that do not require time sequential specifications to make truly beautiful code. We need to abstract away from time to encounter real beauty. This perhaps explains my preference for declarative and functional programming where sequntiality is not explicitly specified. When you free yourself from this over-specification there is more beauty.

The article ends with a nice quote from Buckminster Fuller:

When I am working on a problem I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong.

...

Use case authors similarly recognize that sequencing does not always need to be strictly specified. To quote Alistair Cockburn:

The astute reader will spot that I have used the word sequence rather loosely. In many In many cases, the interactions don’t have to occur in any particular sequence. To buy that 80-cent drink, I could put in eight dimes, three quarters and a nickel, or ...(you can fill in the list). It doesn’t matter which coin goes in first.

Getting back to the first quote above, as insightful as it is, it seems to me that functional programming isn't the whole answer. You can focus on the functions (and how some of them will interact) for quite a while without thinking much about what order they will be called in, but at some point you still have to recognize that they're going to be called in some order for a particular execution of a use case. Some sequences will work and others will not, and need to be anticipated and handled. But how do we do so in a way that is elegant and understandable, even beautiful? That's the real question.

I have to admit that talk about beautiful code strikes me as a little strange sometimes. I think the real beauty of great software is in the final product, and what we create with it. Those who lament the amount of time many of us spend staring at screens have a point - we miss many beautiful things in life if we forget that technology at its best is a tool for greater engagement with the real world and real people, beyond just admiring how "cool" technology often is in itself, or how brilliant and well-architected a solution may be from the perspective of the programmer. But whether or not we consciously value and focus on beautiful code, I think Buckminster Fuller is right in the sense that when a system has been designed and coded exceptionally well, both the code and the final product are beautiful. And we have all seen examples of the opposite too :-P

[James O Coplien]

Sendt fra min iPhone

> Den 19. apr. 2016 kl. 05.27 skrev Matthew Browne <mbro...@gmail.com>:
>
> Getting back to the first quote above, as insightful as it is, it seems to me that functional programming isn't the whole answer. You can focus on the functions (and how some of them will interact) for quite a while without thinking much about what order they will be called in, but at some point you still have to recognize that they're going to be called in some order for a particular execution of a use case.

No. There is no sequencing in functional programming.

[Matthew Browne]

I wasn't suggesting otherwise (well, depending on definition of terms).
Obviously if you have nothing but functions, as a programmer you can
call those functions in any order you see fit. But for most use cases
and also lower level algorithms, sequencing matters for at least some of
the steps of the process.

[James O Coplien]

Sendt fra min iPhone

> Den 19. apr. 2016 kl. 16.41 skrev Matthew Browne <mbro...@gmail.com>:
>
> e functions in any order you see fit. But for most use cases and also lower level algorithms, sequencing matters for at least some of the steps of the process

For use cases — yes. For functional programming there might be computational dependency, but that is not sequencing.

[Raoul Duke]

This is to me always an interesting UX sticking point of confusion and
fogginess in software development and CS. Like, when you start using
Scheme they say "oh these are not sequences of statements but
expressions" but then of course one quickly ends up using syntax that
lets you do things in sequence.

I would guess that a lot of people (for whatever reason!) approach
writing down the code in a linear recipe fashion. It is nice if the
computer doesn't require that, and can infer interdependencies
properly to e.g. squeeze our parallelization or whatever other
optimizations might help (although of course then you get into bugs in
the system there and it can be very "heisenbug"ish which frankly is an
indictment of it all in my mind). But it is nice if the computer lets
us pretend we are doing stuff in a sequence even if that doesn't turn
out to be required, once the dependency analysis happens (including
I/O of course).

It isn't really ever all that obvious to me when looking at functional
code what is or is not sequential because of all that, tho. I have to
stop and think about it. Maybe because I do so much non-fp in life,
and only rarely ever get to go the fpish route.

[Matthew Browne]

Getting back to the more concrete question of how to handle communication between MVC and a use case that involves multiple interactions with the user, I have some new ideas. I should start by saying that part of why I've found this a challenging question is that my previous approach hasn't personally caused any problems for me - i.e. my previous approach of simply creating multiple trigger methods to represent each user interaction (as Marc did in the shopping cart example and I did in my class registration system, and which Quang apparently has also been doing successfully). So hopefully I'm not solving a problem that doesn't even need to be solved in my case, but after Cope's strongly-worded criticism of that approach, I've been thinking about how this could in fact be a problem and what better alternatives there might be.

Most of my experience has been as a solo developer, but one potential problem I can foresee with my prior approach is that if the trigger methods in the Context are all public methods, another developer could come along and call those methods in the wrong order. (And of course it's important that I be responsible about such things for the sake of the next programmer and the users.) At the end of the day it's each programmer's responsibility to work carefully and not screw up the design intended by the original developers or team lead, but we all know that access restrictions are very helpful to discourage misuse and document intended use.

So one solution might be to add a new type of access level ensuring that only the appropriate object - probably an MVC controller - has the ability to call trigger methods other than the one that begins the use case (e.g. processProductSelection() in the shopping cart example [which could alternatively be called addProductToCart]). Something like friend classes in C++.

But that still outsources the sequencing logic / doesn't keep it all in the use case Context where it belongs if we want to truly have a direct mapping between the use case and the code.

So here's another idea...what if we simplified the asynchronous nature of user input in a GUI by providing a programming interface that looks synchronous? We could do that by including the Controller as a role in the use case Context, but in a different way than I tried before. To take the library borrowing example, consider this code snippet:

    stageprop Borrower {
        public void borrowItem(ItemRecord item) {
            Loan loan = new Loan(Borrower, item);
            item.validateAvailability(Borrower);
            Database.save(loan);
           
            Librarian.askForNextItem();
        }
    }
    requires {
        int id();
    }
   
    role Librarian {
        public void askForNextItem() {
            Controller.showMenu();
           
            Command cmd = Controller.awaitNextCommand();
            switch (cmd.name) {
                case "borrow-another":
                    Borrower.borrowItem(cmd.arguments[0]);
                    break;
                case "finish-with-receipt":
                    ...
                case "finish-without-receipt":
                    ...
            }
        }
    }
   
    stageprop Controller {}
    requires {
        Command awaitNextCommand();
    }


The only thing we require from the Controller is the awaitNextCommand() method, so the UI code is kept separate, and it wouldn't even necessarily have to be controlled via a GUI; it could be called by any object that provides an awaitNextCommand() method. The role could alternatively be named UI instead of Controller if Controller is deemed too implementation-specific. awaitNextCommand() returns a "command", meaning what I think matches the definition Trygve wrote in the glossary. The Controller decides which user events qualify as commands that the use case should know about. (All commands are triggered by user actions/events, but not all events are commands).

I have an idea of how to implement this in Javascript using async/await and I will try it sometime soon. I imagine that the code above could work in the trygve environment with the addition of some sort of lightweight concurrency, perhaps inspired by Cope's technique for implementing command-line input.

Have I offered a good solution to this challenge? Let me know what you all think.

[Matthew Browne]

I overlooked that the showMenu() method should also be in the contract for the Controller role:

    stageprop Controller {}
    requires {
        void showMenu();
        Command awaitNextCommand();
    }

So in a way, the use case Context does still have some knowledge of the UI. But how to prepare and display the menu is still up to the View and the Controller. The Controller could of course provide a more abstracted interface to avoid getting even as specific as referring to a "menu", but I'm not sure that's necessary in this case.

[Raoul Duke]

Our type system should let us, and we should, define temporal constraints & relationships. And explore them, generate automatic fuzz tests from them, hive us interactive queries about them, etc.

[Hai Quang Kim]

Actually I like Cope's idea to have one and only one entry point per Context.

All the roles should explicitly play with each other in the Context boundary.

In reality I have to support multiple entries per context (due to existing framework code in place that cannot be changed)

But In general I am very cautious with adding a new entry.

It is hard to guess what would be the order of those entries.

Those entries' name usually indicate the order (init, deinit, update, trigger)

And when I see a context that has too many entries it is a bad sign and it needs to be refactored into multiple contexts.

/quang

[Matthew Browne]

Yes, those are the problems I attempted to address with my proposed solution. I didn't show the full code (because I haven't written it yet), but the idea is that there would only be a single entry point, which could be called start() or perhaps something more descriptive. All subsequent user interaction (until the end of the use case) is managed internally within the Context, although it does delegate UI-specific concerns to MVC.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[Hai Quang Kim]

FYI

This is how I did it for Prokon in C# with WPF, the modal form to fill in info for activity plays role in Context:

https://github.com/wangvnn/DCIProkon/blob/master/src/ProkonDCI/SystemOperation/ActivityAdding.cs

And this is how I did it with Marvin which allows only 1 entry (interaction) so I have to break the use case into 3 use cases:

(start, stop, update)

https://github.com/wangvnn/DCIvsAOP_RibbonApp/tree/master/RibbonAOP/MyRibbonDCI/02%20Presentation/02%20Context

In reality, I tend to combine 3 use cases into one context with 3 entry points (start, stop, update..) which is easier to read for me.

I am not sure which one is the best yet. Let me know if you find out something more interesting :)

/quang

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

[James O Coplien]

Den 24/04/2016 kl. 21.55 skrev Matthew Browne <mbro...@gmail.com>:

So in a way, the use case Context does still have some knowledge of the UI. But how to prepare and display the menu is still up to the View and the Controller. The Controller could of course provide a more abstracted interface to avoid getting even as specific as referring to a "menu", but I'm not sure that's necessary in this case.

Just to raise the level of discourse: what problem does that solve?

Constantine created the concepts of coupling and cohesion to optimize the degree to which local functions accessed only other local functions and local data, and that local data referred only to other local data. Yet a system comprises codependent modules: if they are completely decoupled, it is not a system, but just a collection of parts.

Coupling is always an artefact of how the system is decomposed into parts. Given any decomposition, some of the coupling is essential and some is accidental. Given any decomposition (e.g., an object composition for a given mental model) the goal is not to minimize coupling nor to maximize cohesion. It is rather to minimize the amount of accidental coupling between modules. The essential coupling remains.

The major properties of coupling and cohesion are a natural consequence of the choice of paradigm and the application of that paradigm to create a solution to a given problem. The argument is that a highly cohesive design facilitates local decision-making while a design with much external coupling requires coordinated changes (e.g., across teams, per Conway’s Law and Trygve’s MVC pattern). Yet if teams are not mutually aware of real business dependencies, working independently is a liability rather than a benefit. Recognition of essential coupling is critical to good design and maintenance of a design over time.

The reason DCI works is that it gathers together entities that are tightly coupled — not because it better reduces coupling between objects. In fact, the whole problem is that inclusion polymorphism de-couples classes that should in fact be more tightly coupled!

How does your above suggestion optimize these considerations?

[James O Coplien]

Den 25/04/2016 kl. 06.37 skrev Hai Quang Kim <wan...@gmail.com>:

In reality, I tend to combine 3 use cases into one context with 3 entry points (start, stop, update..) which is easier to read for me.

Do you mean 3 scenarios, or 3 use cases? A use case usually comprises multiple related scenarios.

[Hai Quang Kim]

Yes, it is more like scenario than use cases.

The pong example gives me a better idea to refactor my code to have less and even 1 entry for context.

This is what I have with my code:

I have a context with 2 roles (engine, simulation (simplified to one roles, I actually have many roles here) )

Engine can give 3 events: start, run, stop

and Simulation can listen (link) to 3 events then do some thing. 

My issue is it is hard to find a mechanics to put the engine into the context. (in existing code base/framework)

And because the engine is staying out of the context, it needs 3 entry points to trigger the context for the simulation.

( I can separate them into 3 contexts, but my mental model tells me that they should stay in the same context)

With the pong example in mind, I will find a way to put the engine object into the context then from outside I will only need 1 entry point to trigger the context. Inside the context, then engine can talk to simulation and the code might be more readable.

I think for people who are trying to use DCI with existing code base like WPF MVVM, ASP.NET MVC, or game engine...

It takes more time to get close to what we can do with DCI in trygve.

But all the examples in trygve started to pay off very nice. It inspires me to improve my poor-man DCI code :)

End of the day, no matter what we do (event driven, OOP, DDD...) 

Objects still need to be connected to work together.

It is just the matter of making those invisible connections more visible so that we can read, review, argue about the code.

For this purpose, DCI works best so far for me :)

/quang

[James O Coplien]

Den 25/04/2016 kl. 09.00 skrev Hai Quang Kim <wan...@gmail.com>:

Yes, it is more like scenario than use cases.

A good use case is almost always a compression of multiple related scenarios. And each scenario may have its own “entry point.” This is perfectly in concert for how the system use case world models such things. My Contexts almost always have multiple scenarios. In the bank account examples, there is an Insufficient Funds scenario, a main success scenario, and others. But it’s all the same use case. What ties them together is a common business goal.

The pong example gives me a better idea to refactor my code to have less and even 1 entry for context.

Be a bit careful with the pong example. Take what inspiration you can, but think carefully. It was a hastily assembled piece of code to get graphics up and running.

One of the reasons I did pong is that it is rich in possibilities for exploration. There is one system use case for the trajectory of the ball. There is another (albeit simpler) use case for trajectory of the paddle. There is an algorithm that evaluates whether the ball has struck the paddle. So I see at least three Contexts here. I do feel strongly about that.

Then when you start having multiple balls… it becomes much more obvious.

Then there are messy issues caused by the inadequacies of Java. What does “move the ball” mean? Does it mean to first redraw the ball in the background colour, and then reset the coordinates of the ball, and then redraw it? Or is there a larger cycle that erases the entire screen every 20 milliseconds (in another Context), so I don’t have to do the erase? And then, of course, Java throws in an intermediate object persistence layer called the Panel which is just a collection of graphical objects that will be redrawn unless they are removed (and removal from the Panel is a different operation — at a different level of abstraction boundary — than erasing from the display…)

My implementation is basically a polling implementation; however, the polling queries a state (the mouse position) that is set by asynchronous events. The example has an event handler. Event handling uses roughly the same mechanism as does the single-word read from a Panel: it’s based on blocking, as well as having multiple logical program counters (and multiple trygve stacks, etc.). When one has multiple program counters, parallelism raises its ugly head, and the natural tendency is to have one Context for each program counter. This is very much in line with the Actor model and is in line with Kay’s later thinking. Trygve found this distasteful (as do I) and asked for a change to trygve that allows him to query the mouse position synchronously. That’s one less Context. I am not yet sure which of these approaches I will end advocating, but I do think that a very interesting question lurks here. And it certainly falls under the header of “DCI and Time”.

I think the solution may lay along the lines of something like 之间 (may not be a good translation from the Japanese… I know this has an everyday sense in Chinese but the Japanese use the analogous term for the contextualization of an event or “interval” in a certain spatial configuration, so it is much more than “interval” or “between") and I’ve been exploring this with my Japanese friends for whom the concept of 間 (“ma” in Japanese Kanji) is native. The stuff that Rune and I have been exploring in the functional and applicative domains is of the same nature. The problem is that we usually view events as being discrete, and that messes up the world by introducing state: there is a state before the event, and a new state afterwards. Without events, there would be no state. People fail to understand that state is inextricably tied up with time.

— Cope

[Hai Quang Kim]

Yes DCI tells us to focus on building good network of objects.

The HOW is still quite hard for different cases especially when we are in the golden era of event driven paradigm. (events are everywhere)

But thanks of sharing all the info, it helps me a lot :)

/quang

[Matthew Browne]

On 4/25/16 2:28 AM, James O Coplien wrote:

Den 24/04/2016 kl. 21.55 skrev Matthew Browne <mbro...@gmail.com>:

So in a way, the use case Context does still have some knowledge of the UI. But how to prepare and display the menu is still up to the View and the Controller. The Controller could of course provide a more abstracted interface to avoid getting even as specific as referring to a "menu", but I'm not sure that's necessary in this case.

Just to raise the level of discourse: what problem does that solve?

Avoiding mention of a "menu" in the BorrowLibraryItems context might be going further than needed, but the problem I am aiming to avoid is mixing UI details with use case logic, leading to code that is less understandable and manageable. In this case we could make a good argument that presenting a menu to the user is a part of the use case itself - menus can be displayed in multiple ways, so calling Controller.showMenu() doesn't really couple the BorrowLibraryItems context with the UI too much.

Trygve just explained his motivation for separation of concerns in the other thread:

The current thoughts in Alan Kay's group was that objects should be visible and tangible.  I faced the problem that there an activity should be made visible in many different ways. There was also the problem of making structures of related activities visible on the screen. I had always been a fan of separation of concerns. In particular, I advocated that there should be a separation between the UI part of the program and the part with the actual subject matter (a Plan, a Ledger, an Inventory...) With this separation, programs could be run by other programs as well as by humans.

I'm mainly concerned about code comprehension. As a reminder, I made an earlier attempt at implementing this use case (as an experiment) in which the Controller and Views played roles in the context:

https://gist.github.com/mbrowne/97bcb11fbc56993ac337

Trygve criticized it for having a weak separation of concerns, which is my main concern about it as well. I find it distracting when trying to follow the use case logic to see code concerning specifics of the UI. I think the limits of human working memory and attention also motivate such a separation of concerns. And the separation has other benefits as well: as Trygve pointed out, "programs could be run by other programs" (which also helps for both exploratory and automated white-box testing), and I would add that this also allows the same program to have multiple UIs.

Another recent quote from Trygve that sums it up:

The fundamental idea of MVC is to separate the code for the substance (i.e., the Model) from the I/O. There could be contexts for the operations on the model and separate contexts for the IO (View/Controller). You can find an example of this separation in my big planning example. A single context that combines the M and the V/C behaviors would violate this idea.

My goal is not to artificially eliminate essential coupling, but simply to maintain a separation between presentation and use case logic.

[James O Coplien]

Right now I am looking at topological data for a plot of land. The view should render a view of this plot with contour lines, vegetation covering, color-coding of roads, lakes, streams, and buildings.

If I separate the Model and View fully, then there is an awful fat interface between them and understanding all the methods necessary to retrieve those data (and to make sure the returned data are correlated with respect to the coordinates that tie them together) gets in the way of understanding the code.

I would much rather put all of this logic in one class.

You can still separate out the notification logic (which is really what MVC seems to be about) into Roles or perhaps even into Java interface methods. That is, in this design, it may be better to separate MVC as a concern from the topographical data and their presentation than it might be to separate the data from its presentation.

A proper measure of coupling and cohesion would show this to be a better design — particularly in light of how the model and view evolve together. One can reason otherwise at the level of abstract principles, but when it actually comes down to code comprehension and locality of change, I think that it’s a win to separate the MVC mechanism from the Model-View class.

That is, "mixing UI details with use case logic” is not ipso facto a problem to be solved.Your present it as though it is. There may be some rationale for your designed separation, but given this analysis, this alone cannot be it.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

[Matthew Browne]

Hi Quang,

To add to what Cope said:
> But it’s all the same use case. What ties them together is a common
> business goal.

An essential property of a use case is that it aims to achieve a goal of
the primary actor (usually a user, except for internal use cases).

On 4/25/16 12:37 AM, Hai Quang Kim wrote:
> In reality, I tend to combine 3 use cases into one context with 3
> entry points (start, stop, update..) which is easier to read for me.

As Cope pointed out, these are not separate use cases...actually they
might not even be separate scenarios, but rather different stages in a
main success scenario, although I don't have a clear understanding of
your application so I'm not sure.

You could certainly have multiple Contexts that help to implement a use
case. But a "user goal"-level use case should obviously strive to
achieve the user's goal. So in the shopping cart example, adding an item
to your cart is not in itself a use case, because it doesn't do you any
good unless you check out. So "Place Order" is the use case, but there
could be subfunction-level use cases, e.g. "Pay for Order", implemented
as nested contexts.

I haven't thought as much about how this applies to games, where the
nature of the use cases is somewhat different. It might be interesting
to write the use cases for the pong example and specify what the primary
actors and goals are.

[Matthew Browne]

You're right; separating the Model and View can sometimes weaken readability rather than improve it. I imagine that's why Trygve said that in some of his implementations, it made sense for the Model, View, and Controller roles to all be played by the same object. But in my experience, with most use cases it's the other way around. In the shopping cart example, I maintain that including all the controllers and views within the Place Order context (or even within nested contexts for its subfunctions like Pay for Order) would be distracting and make it harder to understand and maintain the code. Based on my investigation so far, I currently have the same opinion regarding the library borrowing example, although there's more room for debate there.

There are additional considerations. In the MVC Pattern Language document, the "Model/Editor Separation" pattern is motivated by the following problem:

The user may want to inspect and edit information that exists in a business object.

• These objects may not be directly accessible from the node holding the user interface

• The objects may be too complex to be viewed directly

• Different tasks may require different presentations and operations on the same information; each version highlighting some aspect and suppressing something else.

I find that I encounter the third bullet point most often, and that many use cases have at least one instance of that.

[Matthew Browne]

On 4/25/16 12:37 AM, Hai Quang Kim wrote:

> And this is how I did it with Marvin which allows only 1 entry
> (interaction) so I have to break the use case into 3 use cases:
> (start, stop, update)
> https://github.com/wangvnn/DCIvsAOP_RibbonApp/tree/master/RibbonAOP/MyRibbonDCI/02%20Presentation/02%20Context

Ah, I remember that example. I probably wouldn't use DCI at all for that
use case. I think Rune said at some point that DCI at least doesn't get
in the way even when it's unnecessary (as long as it's a suitable
problem for OO in the first place), so technically using it here isn't
causing any problems. But I fail to see what advantage DCI brings to
this use case over regular OO.

[Rune Funch Søltoft]

> Den 25. apr. 2016 kl. 06.37 skrev Hai Quang Kim <wan...@gmail.com>:
>
> And this is how I did it with Marvin which allows only 1 entry (interaction) so I have to break the use case into 3 use cases:
> (start, stop, update)

If that's the case it's a bug

[Trygve Reenskaug]

I believe the usual way of solving this is with overlays having a minimal map at the bottom. Each overlay could show a  visible and tangible object. There could be a model for each overlay that describes points of interest with their coordinates. A Controller would manage the layers... Sounds to  me like very clear separation of concerns since there need not be any relationships between the layers. (Think the stacks of transparent slides we used on the old overhead projectors)

--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      mailto: try...@ifi.uio.no
Morgedalsvn. 5A       http://folk.uio.no/trygver/
N-0378 Oslo             http://fullOO.info
Norway                     Tel: (+47) 22 49 57 27

[Trygve Reenskaug]

Cope's problem leads to an interesting continuation of the never-ending discussion about "what is MVC"? I usually say that with MVC, there is a Model with one or more presentations called Views. Here, there are several independent Models while it's obviously still MVC. May be MVC should be defined by an extensible pattern language. In this case, we need two patterns: One with a single Model, another with several independent Models.

BTW, I had forgotten that "my" MVC pattern language started in one of Cope's workshops. And I don't remember the other members of our group that also contributed. A real pattern language does not have an author but is a community effort. It does not belong in a printed and signed document. It belongs in a Wiki like Wikipedia where it can grow in beauty and substance.

[James O Coplien]

Den 26/04/2016 kl. 08.04 skrev Trygve Reenskaug <try...@ifi.uio.no>:

A real pattern language does not have an author but is a community effort. It does not belong in a printed and signed document. It belongs in a Wiki like Wikipedia where it can grow in beauty and substance.

+1.

I wish that the pattern folks understood this...

[Matthew Browne]

A living, evolving pattern language for MVC is a wonderful idea. I'm not sure if you literally were suggesting that Wikipedia would be a good place for it, but I wonder if it might be better for it to be worked on and extended somewhere else first (maybe its own wiki). I do think Wikipedia would be a good place for it eventually. My concern is that most people in the software community have a mistaken idea of what a pattern is, so anyone with an opinion on their favorite MV* framework or technique could potentially add "patterns" that are nothing more than myopically technology-focused techniques that in some cases detract from the essence of MVC. But I also think a balance should be struck so that contributions are not limited to only those who have studied patterns in great depth. The work of Alexander is very important and we should continue to encourage people to study it (including me ;) ), but it would be rather limiting to first require everyone to read several long books and articles before making even small contributions. And I gather that patterns are about more than book knowledge: an appreciation of patterns in nature and their beauty is fundamental. Perhaps the wiki site could include a brief introduction to patterns that would inspire people to learn more, so that anyone seeking to contribute would at least be made aware of the original meaning of "pattern" and "pattern language".

Regarding Wikipedia...on the other hand, this would probably be its own article, "MVC Pattern Language", rather than in the main MVC article. So perhaps it could initially be published and refined by a small team without too much interference from anonymous users who don't know what patterns are about.

[Matthew Browne]

One last question about MVC resources: does anyone know when/where the
term "direct manipulation metaphor" was first used in print?

[James O Coplien]

Schneiderman in 1974.

http://faculty.utpa.edu/fowler/csci6363/papers/Hutchins_1985_DirectManipulationInterfaces_HCI.pdf

> Den 26/04/2016 kl. 13.39 skrev Matthew Browne <mbro...@gmail.com>:
>
> One last question about MVC resources: does anyone know when/where the term "direct manipulation metaphor" was first used in print?
>

[Matthew Browne]

Thank you.

[Trygve Reenskaug]

And I wish that the pattern folks had established such a Wiki long ago and maintained it.

[James O Coplien]

> Den 26/04/2016 kl. 15.12 skrev Trygve Reenskaug <try...@ifi.uio.no>:
>
> And I wish that the pattern folks had established such a Wiki long ago and maintained it.

One of the great misjudgements that we made in the pattern community was to try to avoid all forms of centralization at all costs. We were very unhappy with the power wielded by professional societies (ACM, IEEE) and by their rather arbitrary policies that got in the way of disseminating “good stuff.” We in Hillside wanted to wash our hands of any of that crap, so we didn’t ever put a centralized repository in place.

Along with this we wanted to be non-profit, which meant no sponsors, so we couldn’t be held accountable to any business interest. So there was no money to fund such a site.

Last, we were interested in creating books. Real books — not electronic versions. We knew (and I still believe) that all electronic media are ephemeral. This one, society still must solve. Google, I think, is on its way there.

— Cope

[Raoul Duke]

> Google, I think, is on its way there

Scary to me.

[Matthew Browne]

I have now implemented the idea I described here in Javascript:
http://mbrowne.github.io/babel-dci/examples/LibraryBorrowing/

Code: https://github.com/mbrowne/babel-dci/tree/master/babel-plugin-transform-dci/examples/LibraryBorrowing

Any feedback would be appreciated.

Javascript is single-threaded of course, so this example demonstrates that it's possible to handle user events within a Context in a synchronous style without multiple threads, if the language supports it or via source transformation. I'm referring here to the Screen.askForNextItem() method (and its communication with the Controller). It's my current opinion that this makes the code more readable than it would be to do it asynchronously with event listeners, and also ensures that the use case steps proceed in the correct order. So I imagine this would be a useful approach in other languages as well, including trygve. My JS implementation uses the proposed async/await feature, which is single-threaded, but given the option of a similar coding style with lightweight or maybe even full-fledged threads, it's certainly one I would consider. As to trygve in particular, I imagine that other proposed features might be more important at the moment, but eventually it would be nice to have something similar (at least from the programmer's perspective) to what I implemented here in JS. I think it could be useful for other examples as well, including the shopping cart example. (The shopping cart example would probably also better demonstrate the usefulness of the approach, but I thought I'd start with a simpler example.)

Some other notes about the example:

- I did not implement the library card authentication yet; I implemented it as if the user has already successfully authenticated. Also, it's not a literal translation of the use case but rather my own implementation of the same requirements. I think it's still pretty close to Andreas's use case so I didn't write my own use case description, but I might do so in the future, especially if there is continued interest in this example.

- I used ractive.js (a simple templating and data-binding library) for the UI, which made it unnecessary to write my own View objects, but I still aimed to adhere to MVC.

- In theory, the code is mostly strongly-typed and intended to be type-checked at compile-time with flow (including the role-object contracts). In reality, I've encountered several issues getting my generated code to actually type-check in flow (including a bug in flow), so for the time being all the contracts and type hints just serve as documentation and aren't actually enforced. Obviously it would be a priority to fix this before using babel-dci (my JS DCI library) in production.

Thanks,
Matt

[Raoul Duke]

http://lambda-the-ultimate.org/node/1435

[Raoul Duke]

Maybe run it thru Typescript's inference &c.

[Matthew Browne]

One other small thing about the code: I wanted to explain my choice of
keyword for role-object contracts - I'm using 'contract' rather than
'requires' as in trygve. This was only because "require" is an
overloaded word in Javascript due to its use in node.js as well as
require.js and other AMD loaders. I would have preferred to make it
'requires' since I think the code reads more naturally that way, and
maybe I'm overestimating the potential confusion if I were to use
'requires'. So if anyone cares to comment on that, either here or
off-list, I encourage you to do so as I'm not fully decided on this.

[Matthew Browne]

I'm wondering if it would be useful to add support for fibers to trygve. Here's an article about a library that implements fibers in Java:
http://www.larsan.net/2014/07/12/java-8-light-weight-threads/

Since they're more lightweight than threads, I think they might be a good fit for asynchronous communication for which real threads would probably be overkill - more routine stuff like communication between MVC and a Context. I'm not sure, but I think that if done well, fibers could perform just as well as events or callbacks, while offering readability advantages. Fibers could be used as the underlying implementation for a higher-level syntax such as async/await.

I'm suggesting fibers because I suspect they might be easier to implement than some other alternatives to threads. Egon mentioned goroutines recently, which have a lot of nice features, but probably more than needed for a research language. For that matter I suppose that just regular threads might be sufficient for trygve, but I was thinking it would be nice to have at least an approximation of what we regard as an optimal real-world approach.

BTW this goes beyond just communication between MVC and Contexts, which I don't think we've explored enough yet...regardless of that, the addition of a lightweight concurrency API could be useful for other experiments involving asynchronous code.

[Matthew Browne]

On 5/15/16 7:21 AM, Matthew Browne wrote:
> BTW this goes beyond just communication between MVC and Contexts,
> which I don't think we've explored enough yet...regardless of that,
> the addition of a lightweight concurrency API could be useful for
> other experiments involving asynchronous code.

...for example, a trygve web server.

[James O Coplien]

O.K. Waiting for your pull request.