Typically a class (let’s call it TOPCLASS) would use a few other (often smaller) classes to do it’s stuff.
So TOPCLASS is actually - in a sense - “derived” from multiple other classes. But because normal derivation only applies to a class being derived from ONE OTHER class, COMPOSITIONING is the way to go here.
So I was wondering why there seems to be so little written or asked about compositioning in Clarion (on Clarionhub and elsewhere).
I’m pretty sure It’s widely used
I can tell you that I make heavy use of it.
Sometimes you want to use a concrete reference to a different class
other times it’s more appropriate to use an INTERFACE
the advantage to using INTERFACEs is they add flexibility
For instance one of my favorite things in ABC is the WindowComponent
Where the WindowManager has a queue of WindowComponents that it calls into
Generally speaking, i think Clarion programmers largely fall into two groups - those writing classes, and those that aren’t.
If you’re not writing classes its not something you think about. You just use objects in your embed code and move on.
If you are writing classes, then composition is pretty simple (as you’ve seen). Theres not really much to talk about.
Questions and thoughts about when to inherit, when to composit, when to use an Interface, come up on ClarionLive from time to time, but not often. Often it’s either obvious or subjective.
So yes, I’d say its common for those writing classes, its just not terribly interesting to talk about.
We discussed this on a recent Clarion Connect webinar. Back in the early days of OOP (think SmallTalk), inheritance was considered to be super useful, and you tried to use it for everything. Sometimes you needed a class to have aspects of two different classes, so they added multiple inheritance. That caused a whole bunch of confusion.
Composition is the solution for that. The most common metaphor is an automobile. A car includes a frame, engine, 4 wheels, windows, seats, etc. A car is not wheels. A car is not an engine. It is composed of those things, so gets the benefit of them all, but is an abstraction above them.
Then you can easily swap off different types of wheels for the car, provided the alternate wheels use the same base object. Therefore, your composition class should refer to the most basic of those constituent elements, so that swapping becomes easier.
Initially, SmallTalk did not have inheritance. It was an addition that complicated things too much and solved a problem not for languages like SmallTalk but for C++, since it helped to make a list of heterogeneous objects (polymorphism) and then the messages between objects became method calls.
In SmallTalk, being totally dynamic, this problem did not exist.
I imagine that Alan Kay was thinking of something else, as he said when he explained that his initial idea was something similar to what Erlang and its derivatives are today.
In any case, even without polymorphism being necessary, sometimes there are problems where inheritance can help, but in particular I prefer to compose.
Additionally, using classes in Clarion has its great advantage, avoiding using MAP. It is a minor issue, but at the end of the day it is more comfortable.
There is a Wiki article that seems on this Topic … which I am adjusting Topic Name to match.
There are good examples in LibSrc with ABC. Like the BrowseClass inherits ViewManager, implements the WindowComponent Interface. Then for Composition it uses StandardBehavior, BrowseEIPManager, FieldPairsClass, PopupClass and more…
