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:
1. decouple data interface from data implementation;
2. in the regular methods implementation use virtual property methods
instead of direct raw fields; and
3. 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.
