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!

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.

"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.

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/

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.

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/

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.