Re: any way to prevent overriding of .init ?

2011-06-13 Thread Andrej Mitrovic 
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.

Re: any way to prevent overriding of .init ?

2011-06-13 Thread Jonathan M Davis 
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

Re: any way to prevent overriding of .init ?

2011-06-13 Thread Dmitry Olshansky 

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

Re: any way to prevent overriding of .init ?

2011-06-13 Thread Jonathan M Davis 
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