www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Voldemort Types

reply =?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:
Hi,

Regarding this article about Voldemort types:

     
http://www.drdobbs.com/cpp/voldemort-types-in-d/232901591?pgno=2

There's something I didn't understand. I general I understand the 
benefit of hiding the type of the "struct RandomNumberGenerator" 
so it doesn't leak out of the generator() function. But why not 
just document the generator() function as returning a Range? 
Indeed, as it is with auto it seems it might not be very friendly 
to documentation, not documenting the actual return type (a 
Range).
May 08 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, May 08, 2013 18:43:01 =?UTF-8?B?Ikx1w61z?=.Marques 
<luismarques gmail.com> puremagic.com wrote:
 Hi,
 
 Regarding this article about Voldemort types:
 
 
 http://www.drdobbs.com/cpp/voldemort-types-in-d/232901591?pgno=2
 
 There's something I didn't understand. I general I understand the
 benefit of hiding the type of the "struct RandomNumberGenerator"
 so it doesn't leak out of the generator() function. But why not
 just document the generator() function as returning a Range?
 Indeed, as it is with auto it seems it might not be very friendly
 to documentation, not documenting the actual return type (a
 Range).
It probably _should_ document that it's returning a range. Voldemort types just make it so that the exact type is unknown. You still need to know what kind of API it has in order to use it. It's just that at that point, it's _only_ the API that matters and not its exact type. Functions returning auto do need to give enough information about what they're returning for programmers to actually use the return value. Feel free to create pull requests to fix the documentation on any function you find which isn't clear enough. - Jonathan M Davis
May 08 2013
parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:
On Wednesday, 8 May 2013 at 18:41:27 UTC, Jonathan M Davis wrote:
 It probably _should_ document that it's returning a range. 
 Voldemort types
 just make it so that the exact type is unknown.
So why not just declare "SomeRange generator()"? It still doesn't leak out the internal struct and any automatic doc generator should have a easier time extracting the type. There must be something I'm missing.
May 08 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 8 May 2013 at 20:46:55 UTC, Luís Marques wrote:
 On Wednesday, 8 May 2013 at 18:41:27 UTC, Jonathan M Davis 
 wrote:
 It probably _should_ document that it's returning a range. 
 Voldemort types
 just make it so that the exact type is unknown.
So why not just declare "SomeRange generator()"? It still doesn't leak out the internal struct and any automatic doc generator should have a easier time extracting the type. There must be something I'm missing.
"SomeRange" is the internal struct here. There is no "range type" in D, it is duck typing in action.
May 08 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, May 08, 2013 22:46:53 =?UTF-8?B?Ikx1w61z?=.Marques 
<luismarques gmail.com> puremagic.com wrote:
 On Wednesday, 8 May 2013 at 18:41:27 UTC, Jonathan M Davis wrote:
 It probably _should_ document that it's returning a range.
 Voldemort types
 just make it so that the exact type is unknown.
So why not just declare "SomeRange generator()"? It still doesn't leak out the internal struct and any automatic doc generator should have a easier time extracting the type. There must be something I'm missing.
You shouldn't _be_ extracting the type. The whole point of a Voldemort type is that you know what the API is but you generally can't construct the type or doing anything which involves its name (though the typeof operator can make it so that you can declare member variables with it if you absolutely have to). You know the API, because you know it's a range. Its actual type is irrelevant, and you shouldn't need to know it. - Jonathan M Davis
May 08 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, May 08, 2013 at 05:45:35PM -0400, Jonathan M Davis wrote:
 On Wednesday, May 08, 2013 22:46:53 =?UTF-8?B?Ikx1w61z?=.Marques 
 <luismarques gmail.com> puremagic.com wrote:
 On Wednesday, 8 May 2013 at 18:41:27 UTC, Jonathan M Davis wrote:
 It probably _should_ document that it's returning a range.
 Voldemort types just make it so that the exact type is unknown.
So why not just declare "SomeRange generator()"? It still doesn't leak out the internal struct and any automatic doc generator should have a easier time extracting the type. There must be something I'm missing.
You shouldn't _be_ extracting the type. The whole point of a Voldemort type is that you know what the API is but you generally can't construct the type or doing anything which involves its name (though the typeof operator can make it so that you can declare member variables with it if you absolutely have to). You know the API, because you know it's a range. Its actual type is irrelevant, and you shouldn't need to know it.
[...] auto r = generator(); // get Voldemort return value alias RangeType = typeof(r); // convenient name for it RangeType r1 = r; // copy it around as you wish If you need to, say, store it in a struct, you could do something like this: struct S { alias RangeType = typeof(generator()); RangeType r; this() { this.r = generator(); } ... } Having said that, though, it would be nice if we adopted some kind of convention for stating things about the return type without actually naming the return type. Some along the lines of: auto generator() { ... } static assert(isInputRange!(typeof(generator()))); Or maybe an out-contract? No, wait, it has to be static, not dynamic, so we'd need a static out-contract. In any case, DDoc should somehow include this in the documentation so that it's clear what attributes the return type is expected to have. T -- Nothing in the world is more distasteful to a man than to take the path that leads to himself. -- Herman Hesse
May 08 2013