It’s not only normal, but very common for a presenter to contain other presenters. For example, a method is displayed by a MethodPresenter which can be contained by either a ClassPresenter or a SelectorPresenter (showing senders and implementors or a selector). Subjects may create other subjects–for example a class subject has factory methods that create subjects for class and instance methods. However, there usually is no explicit containment of subjects, and no need for it since containment is already tracked by presenters.

The type of the various subexpressions is something called Fragment. Presenter is one of the subclasses of Fragment, notable for having a subject and defining its composition in terms of other fragments (that’s what the #definition method is, and why its type is Fragment). Other Fragments are either simple atomic things such as labels or links, or “generic composers” such as rows, columns or expandable/collapsible things.

- You mention subject = location marker + viewpoint (+ stand-in + utility methods). Might a common subject be something like this?

Loc Marker =
Some Starting Domain Object +
Accessor (path) To Target Domain Object

Viewpoint = Subset of attribute & action on Target Domain objects

- It is normal for a presenter to contain other presenters; how about a subject containing other subjects?

- What are the types (Subject, Presenter, Widget, etc.) of the subexpressions in your definition example:

definition = (

^column: {

majorHeading: (label: subject model name) .

include: (Inspector on: subject model).

etc.

- Can you share any thoughts on how your architecture compares with some elements of the IDE patterns in http://web.cecs.pdx.edu/~black/publications/ModelExtensions.pdf ? In particular, some of the methods you might add on a subject, they would advocate adding as interface (forwarding) methods on the corresponding domain model itself.

Thanks!

I’m not sharing this view: i cannot understand, how well-tested application which using FFI to talk directly with OS could be more dangerous than same application which using primitives?
What the difference between bugs in primitive or your code that using FFI?
They both could lead to VM crash or memory corruption. The real difference is where you go when need to find the bug:
- into gdb to debug VM (where you see an object pointers)
- into debugger in your language environment (where you can explore & inspect any object you may need)

make your choice.

I really like the principled approach that you bring to the frameworks you design. I can’t wait to see what this one looks like “under the hood”.

all the best,

-Anthony

This and the FFI comments are something that probably all programming languages need to improve in.

It’s also always fun to watch the Mac guys tear a UI framework or application apart for failing to understand the Mac OS conventions and philosophy. That is, if any developer intends to write a high quality port to Linux or Mac OS (or Windows), they will always need someone well versed in the conventions of that platform, and have to change the behavior of their UI anyway.

Even making portability simpler isn’t enough to actually port a UI or application. Its great to see a Smalltalk derivative taking the lead and making the porting process simpler rather than hiding platform differences and making it impossible.

Thanks for the always, fun and interesting posts on Smalltalk, Newspeak and language stuff in general and I eagerly await the release of Newspeak when it’s completed.

– Lorenz