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 Luís 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