Beerconf June 2023

[Steven Schveighoffer]

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.