Discussion Thread

This is the discussion thread for the first round of Community Review of DIP 1042, "ProtoObject":

https://github.com/dlang/DIPs/blob/2e6d428f42b879c0220ae6adb675164e3ce3803c/DIPs/DIP1042.md

The review period will end at 11:59 PM ET on January 24, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the Feedback Thread. The Feedback Thread will be the source for the review summary that I will write at the end of this review round. I will post a link to
that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

On Monday, 10 January 2022 at 13:48:14 UTC, Mike Parker wrote:

The Feedback Thread is here:

https://forum.dlang.org/post/kondhvmuactgsorbllka@forum.dlang.org

On Monday, 10 January 2022 at 13:48:14 UTC, Mike Parker wrote:

A small nitpick regarding this dip. Why the name ProtoObject, shouldn't it be something like TopObject?
Also shouldn't it have no deconstructor by definition?

• Alex

On Monday, 10 January 2022 at 13:48:14 UTC, Mike Parker wrote:

I like the description of the Hash, Ordered and Equals interfaces with mixin implementations but perhaps the most interesting interface, Stringify, isn't described. I say "interesting" because of the discussion earlier in the DIP about a @nogc delegate form of toString but then the subsequent silence on that matter and the given definition of Stringify having the single method string toString();. What are the plans for toString and @nogc?

This is a terrible idea, mentioning Java/C# has inspiration shows how far we strayed away from the original idea of the language, it is terrible

If changes made to Object, better be less OOP, i see Rust mentioned with the trait system, why not follow that instead of following Java/C# in the graveyard?

I'm definitely not a fan of the OOP-ization of the runtime, locking it more and more

Does the language not have enough to avoid OOP? let's solve that first!

--

More energy should be spent on Tuple and Tagged Unions.. not on OOP

On Monday, 10 January 2022 at 14:27:31 UTC, 12345swordy wrote:

As long as we're bikeshedding, I'd like to submit RootObject for consideration.

On Monday, 10 January 2022 at 18:12:19 UTC, Paul Backus wrote:

It would be a usability mistake to call the root object for something different than just "object".

It would be better to just move mutex to SynchronizedObject and either use source-to-source updates or give the users descriptive error messages.

D needs to focus more on usability and less on backwards compatibility. Streamline, clean up, not obfuscate.

Use proper versioning and let users decide whether they should upgrade or not. Or provide a compiler option for retaining old behaviour. Just don't add more mess to the mix in an attempt to "fix" things. Do it properly, or leave it as is.

On Monday, 10 January 2022 at 23:48:59 UTC, Ola Fosheim Grøstad wrote:

I agree with you!

I cannot post it in the Feedback Thread but we know where this is heading! It is heading towards subatomic particles. There are so many of them and that world is so complicated...

So streamline, clean up, not obfuscate.

On Monday, 10 January 2022 at 18:09:21 UTC, russhy wrote:

Here we talk about "Object" which - I fail to understand the surprise - it is about OOP.

More than that, since it is a tight dependency between objects and the garbage collector, what improvement will render a @nogc thrown here and there? Currently there is little support în the language for using objects outside gc, I really don't understand why limit the overrides to patterns that will be difficult to satisfy. In my opinion the only qualifier that must be put to these basic functions is @safe. Hashing can be a costly operation (think at files or streams), const will prevent any caching. Comparing strings for example can discover invalid unicode characters, why nothrow? Comparing timestamps may need reading the current time zone, why pure?