digitalmars.D - static methods
- Ivan Senji (16/16) Aug 24 2004 Right now it is possible to call static methods on object references.
-
Stewart Gordon
(27/33)
Aug 24 2004
- Ivan Senji (4/37) Aug 24 2004 You are right! I didn't think of that. But as you say, this can easily
- Regan Heath (10/44) Aug 24 2004 This is a good soln, you're only forced to do this 'ugly' (not IMO) thin...
- Stewart Gordon (11/17) Aug 26 2004 My thought is that to allow overloading purely on static-or-not, while
- Regan Heath (18/32) Aug 26 2004 So you don't agree that...
-
Stewart Gordon
(9/15)
Aug 27 2004
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
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!<snip>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!<snip> 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
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message news:cgfbau$q6t$1 digitaldaemon.com...Ivan Senji wrote: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 :)Right now it is possible to call static methods on object references. I think it would be desirable if this were disallowed!<snip>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!<snip> 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
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...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/Ivan Senji wrote: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 :)Right now it is possible to call static methods on object references. I think it would be desirable if this were disallowed!<snip>function opIndex conflicts with BitArray.opIndex at proba2.d(3) This isn't really neccesary. If it was disallowed to call staticmemberfunctions with object references there would be no more conflicts!<snip> 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.
Aug 24 2004
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
On Thu, 26 Aug 2004 11:31:48 +0100, Stewart Gordon <smjg_1998 yahoo.com> wrote:Regan Heath wrote: <snip>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/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....
Aug 26 2004
Stewart Gordon <smjg_1998 yahoo.com> Regan Heath wrote:On Thu, 26 Aug 2004 11:31:48 +0100, Stewart Gordon <smjg_1998 yahoo.com> wrote:<snip><snip>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. http://www.digitalmars.com/drn-bin/wwwnews?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