www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - any way to prevent overriding of .init ?

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
Right now there are lot of Phobos functionality that fully expects 
A.init to return just that - a default initialized value of type A.

Now consider:
struct A
{
     int i;
     void init(int K)
     {
         //blah
     }
}

Then:
map!"a.i"([A(1), A(2), A(3)]);

for me explodes with :
std\algorithm.d(382): Error: function test.A.init (int K) is not 
callable using argument types ()
std\algorithm.d(382): Error: expected 1 function arguments, not 0
due to this line in std.algorithm:
alias typeof(_fun(.ElementType!R.init)) ElementType;

Any way to circumvent this name lookup oddity and get to built-in property?
If there is, shouldn't we use it throughout Phobos?

The issue is not a theoretical one - it severely limits usability of my 
pull request (not posted because of this) that  makes dirEntries return 
proper InputRange of DirEntry . Namely, DirEntry happen to define just 
such a function (init).

-- 
Dmitry Olshansky
Jun 13 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I'm having the same issue with a COM interface that happens to define
an init method. I've used a COM object inside a struct and used the
'alias this' trick to forward all calls, but for init I had to create
a special 'initialize' method in the struct that would call the COM
object's init method explicitly.
Jun 13 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-06-13 12:50, Dmitry Olshansky wrote:

 Right now there are lot of Phobos functionality that fully expects
 A.init to return just that - a default initialized value of type A.
 
 Now consider:
 struct A
 {
      int i;
      void init(int K)
      {
          //blah
      }
 }
 
 Then:
 map!"a.i"([A(1), A(2), A(3)]);
 
 for me explodes with :
 std\algorithm.d(382): Error: function test.A.init (int K) is not
 callable using argument types ()
 std\algorithm.d(382): Error: expected 1 function arguments, not 0
 due to this line in std.algorithm:
 alias typeof(_fun(.ElementType!R.init)) ElementType;
 
 Any way to circumvent this name lookup oddity and get to built-in property?
 If there is, shouldn't we use it throughout Phobos?
 
 The issue is not a theoretical one - it severely limits usability of my
 pull request (not posted because of this) that  makes dirEntries return
 proper InputRange of DirEntry . Namely, DirEntry happen to define just
 such a function (init).


If init is causing a problem, get rid of it. It's scheduled for deprecation 
anyway, and it arguably never should have been called by anyone other than 
std.file in the first place.

- Jonathan M Davis
Jun 13 2011
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 14.06.2011 0:03, Jonathan M Davis wrote:

 On 2011-06-13 12:50, Dmitry Olshansky wrote:

 Right now there are lot of Phobos functionality that fully expects
 A.init to return just that - a default initialized value of type A.

 Now consider:
 struct A
 {
       int i;
       void init(int K)
       {
           //blah
       }
 }

 Then:
 map!"a.i"([A(1), A(2), A(3)]);

 for me explodes with :
 std\algorithm.d(382): Error: function test.A.init (int K) is not
 callable using argument types ()
 std\algorithm.d(382): Error: expected 1 function arguments, not 0
 due to this line in std.algorithm:
 alias typeof(_fun(.ElementType!R.init)) ElementType;

 Any way to circumvent this name lookup oddity and get to built-in property?
 If there is, shouldn't we use it throughout Phobos?

 The issue is not a theoretical one - it severely limits usability of my
 pull request (not posted because of this) that  makes dirEntries return
 proper InputRange of DirEntry . Namely, DirEntry happen to define just
 such a function (init).


 If init is causing a problem, get rid of it. It's scheduled for deprecation
 anyway, and it arguably never should have been called by anyone other than
 std.file in the first place.


Well, I that what I'm was thinking to do as 'right here, right now' 
solution.
Now taking into account that it wasn't documented before I'll just kill it.
Still, the general issue remains.

-- 
Dmitry Olshansky
Jun 13 2011
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-06-13 13:06, Dmitry Olshansky wrote:

 On 14.06.2011 0:03, Jonathan M Davis wrote:

 On 2011-06-13 12:50, Dmitry Olshansky wrote:

 Right now there are lot of Phobos functionality that fully expects
 A.init to return just that - a default initialized value of type A.
 
 Now consider:
 struct A
 {
 
 int i;
 void init(int K)
 {
 
 //blah
 
 }
 
 }
 
 Then:
 map!"a.i"([A(1), A(2), A(3)]);
 
 for me explodes with :
 std\algorithm.d(382): Error: function test.A.init (int K) is not
 callable using argument types ()
 std\algorithm.d(382): Error: expected 1 function arguments, not 0
 due to this line in std.algorithm:
 alias typeof(_fun(.ElementType!R.init)) ElementType;
 
 Any way to circumvent this name lookup oddity and get to built-in
 property? If there is, shouldn't we use it throughout Phobos?
 
 The issue is not a theoretical one - it severely limits usability of my
 pull request (not posted because of this) that makes dirEntries return
 proper InputRange of DirEntry . Namely, DirEntry happen to define just
 such a function (init).


 
 If init is causing a problem, get rid of it. It's scheduled for
 deprecation anyway, and it arguably never should have been called by
 anyone other than std.file in the first place.


 
 Well, I that what I'm was thinking to do as 'right here, right now'
 solution.
 Now taking into account that it wasn't documented before I'll just kill it.
 Still, the general issue remains.


True. And I would argue that it should probably be illegal to declare a 
function with the name init which is not a free function. Maybe that would be 
unacceptable for some reason, but it seems to me that it would solve the 
problem quite cleanly.

- Jonathan M Davis
Jun 13 2011