www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - static vs non-static method overloading

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Time and time again I've stumbled upon this crippling limitation,
which gives an ambiguity error if you define and refer to this:

struct Jolly
{
    static Jolly opCall()
    {
        // to simulate a default constructor
    }

    real opCall()
    {
        // makes it jolly and returns the jolliness factor
    }
}

If you try to "construct" a Jolly, you get an ambiguity error and if
you hack yourself an instance of it, you'll get the same ambiguity
error if you try to get the jolliness factor.
This particular case can be circumvented by replacing the non-static
opCall with something like makeJolly, but there are cases, when this
won't work.
For instance, the opDispatch, which would allow to do this:

struct Library
{
    void* handle;

    static Library opDispatch(string name)()  property
    {
        auto namez = toUTFz!(const(wchar)*)(name);
        return LoadLibraryW(namez); // of course, it would cache the
loaded library handle in an AA or something
    }

    void* opDispatch(string name)()  property
    {
        auto namez = toUTFz!(const(char)*)(name);
        return GetProcAddress(handle, namez);
    }

    unittest
    {
        alias extern(Windows) void* function(in char*) GetModuleHandleA_t;
        auto GetModuleHandleA =
cast(GetModuleHandleA_t)Library.Kernel32.GetModuleHandleA
        assert(GetModuleHandleA !is null);
        assert(GetModuleHandleA(null) == 0x40000000);
    }
}

The only way to achieve the same result now is to introduce a dummy
structure, which would be returned by the static opDispatch, which in
turn would implement the non-static opDispatch. This is bad, because
it's tedious and has run-time footprint.

Is this supposed to be like this or is it a bug? If it's a bug, what
are the plans (if any) to fix it?

-- 
Bye,
Gor Gyolchanyan.
Apr 18 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-18 12:17, Gor Gyolchanyan wrote:

 Time and time again I've stumbled upon this crippling limitation,
 which gives an ambiguity error if you define and refer to this:

 struct Jolly
 {
      static Jolly opCall()
      {
          // to simulate a default constructor
      }

      real opCall()
      {
          // makes it jolly and returns the jolliness factor
      }
 }

 If you try to "construct" a Jolly, you get an ambiguity error and if
 you hack yourself an instance of it, you'll get the same ambiguity
 error if you try to get the jolliness factor.
 This particular case can be circumvented by replacing the non-static
 opCall with something like makeJolly, but there are cases, when this
 won't work.




 Is this supposed to be like this or is it a bug? If it's a bug, what
 are the plans (if any) to fix it?


I would want to overload on static as well. It has already been reported:

http://d.puremagic.com/issues/show_bug.cgi?id=3345

-- 
/Jacob Carlborg
Apr 18 2012
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Voted up (as well as the related enhancement request).
Please vote up, so it gets fixed ASAP.

On Wed, Apr 18, 2012 at 8:26 PM, Jacob Carlborg <doob me.com> wrote:

 On 2012-04-18 12:17, Gor Gyolchanyan wrote:

 Time and time again I've stumbled upon this crippling limitation,
 which gives an ambiguity error if you define and refer to this:

 struct Jolly
 {
 =C2=A0 =C2=A0 static Jolly opCall()
 =C2=A0 =C2=A0 {
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // to simulate a default constructor
 =C2=A0 =C2=A0 }

 =C2=A0 =C2=A0 real opCall()
 =C2=A0 =C2=A0 {
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // makes it jolly and returns the jolliness =




factor

 =C2=A0 =C2=A0 }
 }

 If you try to "construct" a Jolly, you get an ambiguity error and if
 you hack yourself an instance of it, you'll get the same ambiguity
 error if you try to get the jolliness factor.
 This particular case can be circumvented by replacing the non-static
 opCall with something like makeJolly, but there are cases, when this
 won't work.





 Is this supposed to be like this or is it a bug? If it's a bug, what
 are the plans (if any) to fix it?


 I would want to overload on static as well. It has already been reported:

 http://d.puremagic.com/issues/show_bug.cgi?id=3D3345

 --
 /Jacob Carlborg




--=20
Bye,
Gor Gyolchanyan.
Apr 18 2012