std.random2

[Fawzi Mohamed]

On 01/08/13 22:23, Dmitry Olshansky wrote:
> 09-Jan-2013 00:38, H. S. Teoh пишет:
>> On Tue, Jan 08, 2013 at 07:46:46PM +0100, Joseph Rushton Wakeling wrote:
>>> On 01/08/2013 07:38 PM, ixid wrote:
>>>> I imagine there has been some detailed discussion of the std.nameX
>>>> idea of libraries so forgive me if this has been discussed.
>>>
>>> I appreciate your concern on this point, but I don't think it's the
>>> right thing to focus on in this specific discussion.
>>>
>>> What I really want address is: how do we get the design of std.random
>>> _right_?
>>>
>>> How we go about incorporating that new design into Phobos with
>>> minimal hassle for users is a different issue and one we can face
>>> when the time comes.
>>
>> For one thing, I'd say definitely make RNGs have reference semantics.
>> Passing by value just doesn't make sense; for large generators it
>> consumes too much stack space and risks stack overflow, and in any case
>> copying RNGs unintentionally causes duplicated sequences, which is very
>> bad.
>>
>> For those cases where you *want* to copy an RNG, it should be made into
>> a forward range and then you use .save explicitly.
>>
>> I wonder if it even makes sense to force RNGs to inherit from a common
>> base class, so that reference semantics are enforced even for
>> user-defined types. But this may be a bit too heavy-handed (and it will
>> alienate the no-GC crowd).
>
> I'd push a well working (from my POV) design of polymorphic adapters. 
> The idea is that wrapping is doable but buing the speed back is 
> unsolved problem. BTW there is one for input ranges - InputRangeObject.
>
> Then each generator/distribution defines specific structs and there is 
> one templated polymorphic wrapper that has a common base class.
>
> IMO this gives the best of both worlds (this is how std.digest was 
> designed) at no implementation cost.
>
> The no-GC, performance and "just give me this one little PRGN" needs 
> are served with specific structs.
>
> Then polymorphic behavior with hot-swappable PRNG, "I'm coming from 
> Java/Ruby/..." etc. needs are served with a wrapper + base class or 
> interface. It may even give a per struct aliases of the respective 
> wrapper to be more user-friendly.

I think that is the correct approach, and was what I wanted to write 
yestarday, but I had no internet... a good idea is bound to crop up 
again :).
>
>