I'm working on a simple older idea to get it out of the way in preparation for the more difficult DIPs to come:

https://github.com/andralex/DIPs/blob/ProtoObject/DIPs/DIPxxxx.md

This is not officially reviewable yet, but conveys the gist and could use some early feedback. Any insight will be appreciated.


Thanks,

Andrei

On Wednesday, April 04, 2018 00:49:10 Andrei Alexandrescu via Digitalmars-d wrote:
> I'm working on a simple older idea to get it out of the way in preparation for the more difficult DIPs to come:
>
> https://github.com/andralex/DIPs/blob/ProtoObject/DIPs/DIPxxxx.md
>
> This is not officially reviewable yet, but conveys the gist and could use some early feedback. Any insight will be appreciated.

Two things I can think of after quickly going over it:

1. While issues with attributes and Object are discussed, the fact that Object.opEquals requires casting away const and effectively puts a hole in the type system is not mentioned. I don't know that it's all that critical to mention it given all of the other issues, but it certainly affects how overloading opEquals is going to need to be implemented for ProtoObject. Presumably, the free function version of opEquals will need to be templated with an overload that takes classes which are not derived from Object, allowing opEquals to use whatever attributes are appropriate.

2. What happens if you put synchronized on a member function when the class is not derived from ProtoObjectWithMonitor? I would assume that it would be an error, but the DIP doesn't say.

- Jonathna M Davis

Also specify if it will support typeinfo and downcasting.

On 4/4/18 1:32 AM, Jonathan M Davis wrote:
> On Wednesday, April 04, 2018 00:49:10 Andrei Alexandrescu via Digitalmars-d
> wrote:
>> I'm working on a simple older idea to get it out of the way in
>> preparation for the more difficult DIPs to come:
>>
>> https://github.com/andralex/DIPs/blob/ProtoObject/DIPs/DIPxxxx.md
>>
>> This is not officially reviewable yet, but conveys the gist and could
>> use some early feedback. Any insight will be appreciated.
> 
> Two things I can think of after quickly going over it:
> 
> 1. While issues with attributes and Object are discussed, the fact that
> Object.opEquals requires casting away const and effectively puts a hole in
> the type system is not mentioned. I don't know that it's all that critical
> to mention it given all of the other issues, but it certainly affects how
> overloading opEquals is going to need to be implemented for ProtoObject.
> Presumably, the free function version of opEquals will need to be templated
> with an overload that takes classes which are not derived from Object,
> allowing opEquals to use whatever attributes are appropriate.

Yes, and at some point, we should deprecate the casting version, meaning your Object that doesn't define a const opEquals will stop compiling.

> 
> 2. What happens if you put synchronized on a member function when the class
> is not derived from ProtoObjectWithMonitor? I would assume that it would be
> an error, but the DIP doesn't say.

Error. No place to allocate the monitor.

-Steve

On Wednesday, 4 April 2018 at 04:49:10 UTC, Andrei Alexandrescu wrote:
> This is not officially reviewable yet, but conveys the gist and could use some early feedback. Any insight will be appreciated.

I'm delighted to see this DIP! Best of luck.

If there is a root class, I agree that it should be empty. What are some good reasons to keep the root class?

Associative arrays with immutable key classes rely on opEquals, opCmp, toHash. When a class derives from ProtoObject and an AA is declared, the compiler should statically check whether opEquals, opCmp, toHash are implemented, most likely via template/duck-typing, or maybe by interface. I feel there is no need to tailor ProtoObject towards AAs; that's good.

It's popular to wrap class references in templated structs that then masquerade as class references: std.typecons.Rebindable, or aliak's Optional, or maybe something to enforce a custom restriction at runtime (reference is not null!). These templated structs rely on is(T == class), and it takes a lot of implementation code to make these structs blend in with raw class references. const, inout, opEquals, ..., many things can subtly get in the way. Covariant return types become impossible.

It feels correct to disallow `a == b` entirely for a, b ProtoObjects, even though is(T == class)-templated structs will break when they forward opEquals explicitly. It would be nice to find a catch-all resolution that makes all existing is(T == class)-templates work with ProtoObject, but I doubt there will be one.

-- Simon

On 4/4/18 12:49 AM, Andrei Alexandrescu wrote:
> I'm working on a simple older idea to get it out of the way in preparation for the more difficult DIPs to come:
> 
> https://github.com/andralex/DIPs/blob/ProtoObject/DIPs/DIPxxxx.md
> 
> This is not officially reviewable yet, but conveys the gist and could use some early feedback. Any insight will be appreciated.

Awesome, I remember you talking about this, glad to see it started.

One thing you don't address is the ClassInfo requirement. Every class instance also has a ClassInfo member, which provides runtime type info, and the vtable used to call virtual functions. I think this needs to be discussed in the DIP.

It's a bit confusing that you have typed ProtoObject as extern(C++), since the vtable layouts between C++ and D are incompatible. What does this mean?

-Steve

On Wednesday, 4 April 2018 at 04:49:10 UTC, Andrei Alexandrescu wrote:
> I'm working on a simple older idea to get it out of the way in preparation for the more difficult DIPs to come:
>
> https://github.com/andralex/DIPs/blob/ProtoObject/DIPs/DIPxxxx.md
>
> This is not officially reviewable yet, but conveys the gist and could use some early feedback. Any insight will be appreciated.
>
>
> Thanks,
>
> Andrei

No attempts to make class deallocation @nogc attribute friendly? This is a major PIA for me. The current attempts at this involve various workarounds (See automem library for example), which even then does not solve all the problems it currently have.

On Wednesday, 4 April 2018 at 04:49:10 UTC, Andrei Alexandrescu wrote:
> I'm working on a simple older idea to get it out of the way in preparation for the more difficult DIPs to come:
>
> https://github.com/andralex/DIPs/blob/ProtoObject/DIPs/DIPxxxx.md
>
> This is not officially reviewable yet, but conveys the gist and could use some early feedback. Any insight will be appreciated.

I was going to propose exactly this approach to get rid of the monitor in my objects. It's a huge cache penalty that I have to pay (for no use, because I think monitors are an awful approach to multi-threading) just to get proper reference semantics and some other OO features. If we also get proper modernized objects that's a sweet, sweet cherry on top. Le cool! This is exactly the kind of house cleaning that will benefit D, and I hope to see more of. Very reassuring.

Regarding the output range replacing toString. That's an obvious improvement. Yet, before that is set in stone, give the following at least some thought. I've always wondered about the use of output ranges. Yes, they can be more convenient to implement than input ranges, but they are less convenient to use because they are not composable (unless you create some kind of adapter Fiber that makes them input ranges). For instance, if you want to print an Object to the terminal with some color, you can't use a chain of ranges like `yourObject.toString.colorizer`, you have to output to some intermediary buffer. Just by coincidence, yesterday I was once again wondering about this and I decided to prototype an input-range-based formatter.  By restricting the initial version to a compile-time format string it actually made it *very* easy to implement a MVP. You basically just std.range.chain the first formatter item range and the remaining tail. And you can implement it piecemeal by using sformat to format integers/floats; this (temporarily) requires a small buffer in the range, but avoids the unbounded memory allocation for the stringy parts of the formatting (the literals, etc.), which is the truly problematic part.

On 04/04/2018 09:18 AM, 12345swordy wrote:
> On Wednesday, 4 April 2018 at 04:49:10 UTC, Andrei Alexandrescu wrote:
>> I'm working on a simple older idea to get it out of the way in preparation for the more difficult DIPs to come:
>>
>> https://github.com/andralex/DIPs/blob/ProtoObject/DIPs/DIPxxxx.md
>>
>> This is not officially reviewable yet, but conveys the gist and could use some early feedback. Any insight will be appreciated.
>>
>>
>> Thanks,
>>
>> Andrei
> 
> No attempts to make class deallocation @nogc attribute friendly? This is a major PIA for me. The current attempts at this involve various workarounds (See automem library for example), which even then does not solve all the problems it currently have.

Can you please give more detail on that? You mean the destructor of Object is automatically generated with a bad signature?

On Wednesday, 4 April 2018 at 15:18:30 UTC, Andrei Alexandrescu wrote:
> On 04/04/2018 09:18 AM, 12345swordy wrote:
>> On Wednesday, 4 April 2018 at 04:49:10 UTC, Andrei Alexandrescu wrote:
>>> [...]
>> 
>> No attempts to make class deallocation @nogc attribute friendly? This is a major PIA for me. The current attempts at this involve various workarounds (See automem library for example), which even then does not solve all the problems it currently have.
>
> Can you please give more detail on that? You mean the destructor of Object is automatically generated with a bad signature?

I'm not them, but I think they were referring to the fact that destructors can't be @nogc for classes.

Relevant forum thread:
https://forum.dlang.org/post/pnswjnosrlfazgscuhrs@forum.dlang.org