Reaction vs MUI (as what concerns the API)

[Karlos]

Thread moved from news section

[Karlos]

Strange you should say that as just this very evening I booted up a NOS Escom A1200 with Workbench 3.1, which had "MUI-AT" drawer with a readme that said "MUI 3.2 Amiga Technologies Edition".

No Reaction in sight........

Karlos was here with me and can confirm this as it was he who noticed it first.

Yep. I guess it was to support the included network software?

[Karlos]

After messing around with Nicholas' vanilla 3.1 installed machine yesterday I have come to the conclusion that Gadtools is king :lol:

Gadtools, on a 2:1 aspect display with topaz 8, ftw.

[Karlos]

Let me guess: your GadTools applications have one big eventloop where you control all possible events using switch/case construct?

Ick.

Observer and Mediator patterns, ftw

[Karlos]

Assembly is usually better suited for that.

Some embedded devices are well supported. Amtel AVR springs to mind. Also remember that what is referred to as "C++" on embedded systems is usually a carefully-selected subset of the full language specification.

[Karlos]

If Reaction lacks notification then I would consider it obsolete! I think this answers the OP question, MUI is the more modern design.

Actually, if you know how to use design patterns, this is never a limitation. You can wrap an observer mechanism around absolutely anything that needs event handling to be decoupled from the event source, no matter how old and retarded it is.

[Karlos]

Kitab al-Karlos

Seriously, I cannot recommend that book enough. It's examples are all based on C++ and Smalltalk but no matter which language you use (provided it supports or can achieve basic object orientation), the principles in there can be utilised to great effect. After a while, you see the patterns described therein all over the place, often in interesting combinations. The chances are, you've independently "reinvented" more than one of them without even knowing it. However, once you have seen them formally catalogued (and the book is by no means exhaustive but instead considers the the most fundamental structural/creational/behavioural patterns to which all others can be reduced) and dissected it's very easy to see how to go about solving whatever awkward development job lands on your plate.