View mode: basic / threaded / horizontal-split · Log in · Help
August 24, 2004
static methods
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!
August 24, 2004
Re: static methods
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.
August 24, 2004
Re: static methods
"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!
> <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.

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.
August 25, 2004
Re: static methods
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!
>> <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.
>
> 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/
August 26, 2004
Re: static methods
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.
August 26, 2004
Re: static methods
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/
August 27, 2004
Re: static methods
Regan Heath wrote:

> On Thu, 26 Aug 2004 11:31:48 +0100, Stewart Gordon <smjg_1998@yahoo.com> 
> wrote:
<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....
<snip>
> 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.
Top | Discussion index | About this forum | D home