thank you for your reply. And sorry for answering with this delay (I’ll have to take a look at the settings of the notification-system, again).
I am not quite sure, if your example fits what I imagine.
What would be, if the ChildInterface could extend one of the base classes?
I only need one base class. So the identification of the base class’ fields would not be ambigue. It just would be the complement of the ‘blueprint’ demanded by the interface.
The interface then would say: “If you implement me, you have to implement all of the fields of my parent class as well!” This demand is granted by heritage, as the implementors would have the same base class anyway.
This would allow, having a virtual type for siblings (so having common fields), without the need to cast them.
To make it less abstract:
I am working on a WYSIWYG generator for a dynamic layout for OpenFl. It’s supposed to be as flexible as HTML5 and CSS (but less confusing).
For that purpose I have ‘shelfs in a rack’. These shelfs necessarily hold one displayObject each. But they do not hold the same type of displayObject (e.g. Sprite, TextField, MovieClip, etc.) . So they have a common base. This base class does not know, what displayObject the childClass instance holds.
Each displayObject has its own type shelf (eg.: BaseClass → SpriteShelf)
In OpenFl the Sprite class extends the display class. It has the same base class like a textfield (DisplayObject → Sprite | DisplayObject → TextField).
So, if I could build a ‘virtual type’ via an interface, it would demand the fields of DsplayObject. And of cause also the base class’ fields are supposed to be present as well.
Alternatively casting the baseType (instead of addressing this ‘virtual type’) would cause having a bunch of differently typed instances for within the accrodung functions, which I do not consider to be the best solution.
At the moment I have build an interface for the baseClass, which is extended by the DisplayObjectInterface. This solution is not satisfying as well, as I have to mirror the BaseClass into its own interface which is redundant. It also makes it inevitable, that every work on BaseClass must be done on the interface as well.
The article, I have found, suggests (at least in my understanding) that creating this ‘virtual type’ (an interface extending a class) is possible.
Of cause, there are workarounds. I can reconcile with the thaught, that my preferred solution does not work.
But theoretically, I do not see a problem with the concept.