www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - static methods

reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
Right now it is possible to call static methods on object references.
I think it would be desirable if this were disallowed!

Example:

class BitArray
{
    static BitArray opIndex(int size){} //for creating BitArrays
//this way: "BitArray ba = BitArray[43];"

    int opIndex(int pos){} //to get the state of a bit
}

But i get:

function opIndex conflicts with BitArray.opIndex at proba2.d(3)

This isn't really neccesary. If it was disallowed to call static member
functions with object references there would be no more conflicts!

Before someone calls this operator abuse :) i would just like to say
that there are probabbly more meaningful examples to support
what i am saying!
Aug 24 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Ivan Senji wrote:
 Right now it is possible to call static methods on object references.
 I think it would be desirable if this were disallowed!

 function opIndex conflicts with BitArray.opIndex at proba2.d(3)
 
 This isn't really neccesary. If it was disallowed to call static member
 functions with object references there would be no more conflicts!

Wrong. class Qwert { static Qwert yuiop(int asdfg) {} Qwert yuiop(int asdfg) {} static void hjkl() { writef(yuiop(42)); } void zxcvb() { writef(yuiop(105)); // ambiguous - which yuiop? } } Since hjkl is static, only the static yuiop can be called. But in zxcvb, there are two available yuiops: this.yuiop and Qwert.yuiop. We could require that yuiop be explicitly resolved in zxcvb. But this might be considered ugly. Or we could it have it call the non-static yuiop, which would be consistent in a sense with your idea. But this wouldn't be right. The static and non-static members of one class constitute one scope. For a symbol to have different meanings based on context within the same scope would be confusing. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on on the 'group where everyone may benefit.
Aug 24 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:cgfbau$q6t$1 digitaldaemon.com...
 Ivan Senji wrote:
 Right now it is possible to call static methods on object references.
 I think it would be desirable if this were disallowed!

 function opIndex conflicts with BitArray.opIndex at proba2.d(3)

 This isn't really neccesary. If it was disallowed to call static member
 functions with object references there would be no more conflicts!

Wrong. class Qwert { static Qwert yuiop(int asdfg) {} Qwert yuiop(int asdfg) {} static void hjkl() { writef(yuiop(42)); } void zxcvb() { writef(yuiop(105)); // ambiguous - which yuiop? } } Since hjkl is static, only the static yuiop can be called. But in zxcvb, there are two available yuiops: this.yuiop and Qwert.yuiop.

You are right! I didn't think of that. But as you say, this can easily be disambiguated by specifying this.yuiop or Qwert.yuiop :)
 We could require that yuiop be explicitly resolved in zxcvb.  But this
 might be considered ugly.

 Or we could it have it call the non-static yuiop, which would be
 consistent in a sense with your idea.  But this wouldn't be right.  The
 static and non-static members of one class constitute one scope.  For a
 symbol to have different meanings based on context within the same scope
 would be confusing.

 Stewart.

 --
 My e-mail is valid but not my primary mailbox.  Please keep replies on
 on the 'group where everyone may benefit.

Aug 24 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Tue, 24 Aug 2004 15:44:23 +0200, Ivan Senji <ivan.senji public.srce.hr> 
wrote:
 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
 news:cgfbau$q6t$1 digitaldaemon.com...
 Ivan Senji wrote:
 Right now it is possible to call static methods on object references.
 I think it would be desirable if this were disallowed!

 function opIndex conflicts with BitArray.opIndex at proba2.d(3)

 This isn't really neccesary. If it was disallowed to call static 

 functions with object references there would be no more conflicts!

Wrong. class Qwert { static Qwert yuiop(int asdfg) {} Qwert yuiop(int asdfg) {} static void hjkl() { writef(yuiop(42)); } void zxcvb() { writef(yuiop(105)); // ambiguous - which yuiop? } } Since hjkl is static, only the static yuiop can be called. But in zxcvb, there are two available yuiops: this.yuiop and Qwert.yuiop.

You are right! I didn't think of that. But as you say, this can easily be disambiguated by specifying this.yuiop or Qwert.yuiop :)

This is a good soln, you're only forced to do this 'ugly' (not IMO) thing in certain cases. Your other option is to assume one or the other, the most logical assumption in this case IMO is this.yuiop, however this would likely cause some bugs, so I support the explicit requirement idea. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 24 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Regan Heath wrote:
<snip>
 This is a good soln, you're only forced to do this 'ugly' (not IMO) 
 thing in certain cases.
 
 Your other option is to assume one or the other, the most logical 
 assumption in this case IMO is this.yuiop, however this would likely 
 cause some bugs, so I support the explicit requirement idea.

My thought is that to allow overloading purely on static-or-not, while the parameters remain exactly the same, would be an unnecessary complexity. Last time I knew, static was still one of those attributes that's buggily checked before overload resolution anyway. But now I'm back properly, I'll have to write some more testcases.... Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Aug 26 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 26 Aug 2004 11:31:48 +0100, Stewart Gordon <smjg_1998 yahoo.com> 
wrote:
 Regan Heath wrote:
 <snip>
 This is a good soln, you're only forced to do this 'ugly' (not IMO) 
 thing in certain cases.

 Your other option is to assume one or the other, the most logical 
 assumption in this case IMO is this.yuiop, however this would likely 
 cause some bugs, so I support the explicit requirement idea.

My thought is that to allow overloading purely on static-or-not, while the parameters remain exactly the same, would be an unnecessary complexity. Last time I knew, static was still one of those attributes that's buggily checked before overload resolution anyway. But now I'm back properly, I'll have to write some more testcases....

So you don't agree that... class Qwert { static Qwert yuiop(int asdfg) {} Qwert yuiop(int asdfg) {} static void hjkl() { writef(yuiop(42)); } void zxcvb() { writef(yuiop(105)); // ambiguous - which yuiop? } } Since hjkl is static, only the static yuiop can be called. or.. I'm not sure I follow what you mean't above :) Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 26 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Regan Heath wrote:

 On Thu, 26 Aug 2004 11:31:48 +0100, Stewart Gordon <smjg_1998 yahoo.com> 
 wrote:

 Last time I knew, static was still one of those attributes that's 
 buggily checked before overload resolution anyway.  But now I'm back 
 properly, I'll have to write some more testcases....


 or.. I'm not sure I follow what you mean't above :)

Old bu'g that's been brought up quite a few times before. digitalmars.D.bugs/32 Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Aug 27 2004