On Tuesday, 18 September 2012 at 17:59:04 UTC, Jonathan M Davis wrote:
On Tuesday, September 18, 2012 17:05:26 monarch_dodra wrote:
This is issue #1: I'd propose that all objects in std.random be
migrated to classes (or be made reference structs), sooner than
later. This might break some code, so I do not know how this is
usually done, but I think it is necessary. I do not, however,
propose that they should all derive from a base class.

Moving to classes would definitely break code, but it should be possible to make them reference types simply by making it so that their internal state is
in a separate object held by a pointer.

I was thinking of doing that. The problem with this (as I've run into and stated in another thread), is a problem of initialization: The simpler PRNGs are init'ed seeded, and are ready for use immediately. Changing to this approach would break the initialization, as shown in this post:

http://forum.dlang.org/thread/[email protected]#post-yvtsivozyhqzscgddbrl:40forum.dlang.org

A "used to be valid" PRNG has now become an un-initialized PRNG". This is extremely insidious, as the code still compiles, but will crash.

I'm hoping my thread goes somewhere, but since I doubt it, I've thought up of two other solutions for a "clean" migration:

#1
Keep as struct (as you suggest), but use the opCall hack. I HATE this solution.

#2
Change to class, but leave behind some "opCall"s for each old constructor, plus an extra one for default:
class A
{
    static A opCall(){return new A();}
    static A opCall(int i){return new A(i);}

    this(){}
    this(int){}

    /// ...
}

void main()
{
    A a1 = A();  //Works AND constructs
    A a2 = A(5); //Still Works
    A a3 = new A();  //Works
    A a4 = new A(5); //Works
}

In this case, I'm fine with having some opCalls, because technically, they aren't mixed with the constructors and used as hacks: The constructors are all there, and the opCalls, merelly forward to them.

That said, they *would* be destined for deprecation.

Use of "A a;" would create a problem though, but nothing's perfect...

Is this second solution something you think I should look into?

Reply via email to