Re: DIP in making: ProtoObject
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.
Re: DIP in making: ProtoObject
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
Re: DIP in making: ProtoObject
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
Re: DIP in making: ProtoObject
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/DIP.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
Re: DIP in making: ProtoObject
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/pnswjnosrlfazgscu...@forum.dlang.org
Re: DIP in making: ProtoObject
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/DIP.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?
Re: DIP in making: ProtoObject
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/DIP.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.
Re: DIP in making: ProtoObject
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/DIP.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.
Re: DIP in making: ProtoObject
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/DIP.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
Re: DIP in making: ProtoObject
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/DIP.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
Re: DIP in making: ProtoObject
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
Re: DIP in making: ProtoObject
Also specify if it will support typeinfo and downcasting.
Re: DIP in making: ProtoObject
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/DIP.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
DIP in making: ProtoObject
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/DIP.md This is not officially reviewable yet, but conveys the gist and could use some early feedback. Any insight will be appreciated. Thanks, Andrei
