www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP in making: ProtoObject

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 03 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Apr 03 2018
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Apr 04 2018
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Also specify if it will support typeinfo and downcasting.
Apr 03 2018
prev sibling next sibling parent SimonN <eiderdaus gmail.com> writes:
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
Apr 04 2018
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Apr 04 2018
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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.
Apr 04 2018
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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?
Apr 04 2018
next sibling parent Uknown <sireeshkodali1 gmail.com> writes:
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
Apr 04 2018
prev sibling next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
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:
 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?
There is a bug report already on this. https://issues.dlang.org/show_bug.cgi?id=15246
Apr 04 2018
prev sibling parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Wednesday, 4 April 2018 at 15:18:30 UTC, Andrei Alexandrescu 
wrote:
 On 04/04/2018 09:18 AM, 12345swordy 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 assume this is what was meant: https://issues.dlang.org/show_bug.cgi?id=15246 -- Simen
Apr 04 2018
prev sibling parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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.
Apr 04 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, April 04, 2018 14:47:03 Lus Marques via Digitalmars-d wrote:
 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.
In general, toString's API needs to work with functions like format and to!string. If improvements need to be made to those functions, then they can and should be, but in principle, by having ProtoObject, it's then possible for a class to implement toString however it wants. It puts toString on classes in pretty much the same boat that toString on structs is. The main difference is that any classes derived from that class then needs to worry about how their particular base class declared toString, and part of that then is whether the function was declared as a virtual function or a templated function. Now, declaring a useful toString that doesn't return string gets a bit more entertaining with classes due to the fact that a templated function isn't virtual, but each class hierarchy can then deal with that in the best way for it rather than one particular solution being pushed onto every class. - Jonathan M Davis
Apr 04 2018
prev sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 4 April 2018 at 14:47:03 UTC, Luís Marques wrote:
 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.
It's a bit late for that ;) https://github.com/dlang/phobos/pull/5991
 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.
The counter to this is that output ranges are only for finalizing data that you want to buffered. In the example given, yourObject should instead have a range generating function which can be given to colorizer, which is then given to stdout.lockingTextWriter.
Apr 04 2018