On 6/11/23 4:48 PM, Steven Schveighoffer wrote:
> BEERCONF!
Beerconf for June is happening 2 weeks from now, on the 24-25.
A reminder that this is happening in 2 days!
YuQian has asked that I post the abstract for the talk being given. A reminder that the talk is on Saturday at 19:00 UTC.
See you there!
-Steve
Stop inheriting data fields!
A new design pattern DDIFI (Decoupling Data Interface From data Implementation) as a clean and general solution to multiple inheritance
Abstract
Traditionally in class based OOP languages, both the fields and methods from the super-classes are inherited by the sub-classes. However this may cause some serious problems in multiple inheritance, e.g. most notably the diamond problem. In this paper, we propose to stop inheriting data fields as a clean and general solution to such problems. We first present a design pattern to cleanly achieve multiple inheritance in C++, which can handle class fields of the diamond problem exactly according to the programmers’ intended application semantics. It gives programmers flexibility when dealing with the diamond problem for instance variables: each instance variable can be configured either as one joined copy or as multiple independent copies in the bottom class.
The key ideas are:
- decouple data interface from data implementation;
- in the regular methods implementation use virtual property methods instead of direct raw fields; and
- after each semantic branching add (and override) the new semantic assigning property.
Then we show our method is general enough, and also applicable to any OOP languages that natively support multiple inheritance (e.g. C++, Python, Eiffel, etc.), or single inheritance languages that support default interface methods (e.g. Java, C# etc.).
For example, in the diamond inheritance problem of <Person, Student, Faculty, and ResearchAssistant>,
we want to achieve the ideal application semantics: each ResearchAssistant should only have:
- one (joined) copy of
_name field, but
- two (separated) different address fields:
- one
_student_addr ("dorm") as Student to takeRest(), and
- one
_faculty_addr ("lab") as Faculty to doBenchwork()
Our new design pattern can achieve this.
Also it works for the current D! although it's a bit hackish. With default interface methods it will be better (less convoluted).
(ref: https://github.com/joortcom/DDIFI/blob/main/d/MI.d)
Speaker Bio
Ph.D Oxford Univ.; previous Google engineer; startup founder.
Permalink
Reply
