Rethinking the default class hierarchy: Milestone 1, Week 1

Robert Aron aronrobert293 at gmail.com
Thu Sep 23 10:15:28 UTC 2021


[Project 
description](https://gist.github.com/edi33416/0e592f4afbeb2fb81d3abf235b9732ce)
[SAOC 
projects](https://dlang.org/blog/2021/08/30/saoc-2021-projects/)

Hello!

The project that I have selected is “Rethinking the default class 
hierarchy”.
Every class defined in the D language has `Object`  as the root 
ancestor. `Object` defines four methods: `toString`, `toHash`, 
`opCmp` and `opEquals`, that, at a first glance, might not strike 
you with much but they are doing much more harm than good. Their 
signatures predate the introduction of the `@nogc`, `nothrow`, 
`pure` and `@safe` function attributes and `const`, `immutable` 
and `shared` type qualifiers. As a consequence, these methods 
make it difficult to use `Object` with qualifiers or in code with 
properties such as `@nogc` or `@safe`.\
The goal of the project is to implement the solution proposed by 
Eduard Staniloiu in his talk. We will introduce a new class, 
`ProtoObject`, as the root class and ancestor of `Object`. 
`ProtoObject` defines no methods and requires the user to 
implement the desired behaviour through interfaces: this approach 
enables the user to opt-in for the behaviour that makes sense for 
his class and the design is flexible enough to allow future 
attributes and language improvements to be used without breaking 
code.


Last week I managed to do the following tasks for #SAOC2021:
- read the 
[gist](https://gist.github.com/edi33416/0e592f4afbeb2fb81d3abf235b9732ce) that Edi provided and also watch [his talk](https://www.youtube.com/watch?v=EcG5mnOzZ0s) from Dconf to familiarize myself with the problem and the way we are going to handle it. To summarize this, we are going to introduce a new class `ProtoObject` as the root of all classes. The recommended way of going forward with types that inherit from `ProtoObject` is write and implement interfaces that expose the desired behaviour(order, equality, hash, etc.) that the type supports.
- read about how the default class hierarchy is designed in Java, 
C# and Kotlin:
    - Java has quite a few similarites with Dlang, both defining 
operations like `opEquals` or `getHash`, having similar 
operations (for example `getClass` is simillar to `typeid(obj)`) 
and an `object monitor`
    - Kotlin is similar to Java, as it was designed to 
interoperate fully with Java. In Kotlin the root of all classes 
is represented by the `Any` class and it also the operations 
described above, as well as new ones, such as `apply` and `also`
    - C# stripped a lot from it's `Object`, comparing to Java, 
Kotlin and D, and it comes a lot closer to what we desire. There 
is no builtin monitor. The `Monitor` object is implemented as a 
separate class that inherits from `Object` in the 
`System.Threading` namespace. Also C# has a smaller number of 
imposed methods, but they are still imposed, and `toString` will 
continue to be GC dependent.
- took a look at the [DIPs](https://github.com/dlang/DIPs) to 
familiarize myself with them and read the guidelines

The plan for the next week:
- read about how Rust handles this, since it has a totally 
different approach
- start writing the DIP for the project


More information about the Digitalmars-d mailing list