Hi, the suggestions is this:

In this case:

class A
{
  uint a(char[] b){}
  int a(int b){}
}

Make this syntax valid:

A.a[1]
A.a.length
etc

Regards,
bobef

bobef Wrote:
> Make this syntax valid:
> A.a[1]
> A.a.length

Why? Can you show/tell some purpose of it?

Bye,
bearophile

bearophile a écrit :
> bobef Wrote:
>> Make this syntax valid:
>> A.a[1]
>> A.a.length
> 
> Why? Can you show/tell some purpose of it?
> 
> Bye,
> bearophile


I think he can't have a reference to the second "a" method, because &A.a just returns the first one. So he's asking to treat "A.a" as an array of methods.

Reply to Ary,

> bearophile a écrit :
> 
>> bobef Wrote:
>> 
>>> Make this syntax valid:
>>> A.a[1]
>>> A.a.length
>> Why? Can you show/tell some purpose of it?
>> 
>> Bye,
>> bearophile
> I think he can't have a reference to the second "a" method, because
> &A.a just returns the first one. So he's asking to treat "A.a" as an
> array of methods.
> 

ouch!

better solution

&A.a(char[])
&A.a(int)

On Tue, 12 Aug 2008 01:43:56 +0400, Ary Borenszweig <ary@esperanto.org.ar> wrote:

> bearophile a écrit :
>> bobef Wrote:
>>> Make this syntax valid:
>>> A.a[1]
>>> A.a.length
>>  Why? Can you show/tell some purpose of it?
>>  Bye,
>> bearophile
>
>
> I think he can't have a reference to the second "a" method, because &A.a just returns the first one. So he's asking to treat "A.a" as an array of methods.

Yeah, but how do you distinguish which one is first and which one is second?

"BCS" <ao@pathlink.com> wrote in message news:55391cb3304918cac9d9f784829e@news.digitalmars.com...
> Reply to Ary,
>
>> bearophile a écrit :
>>
>>> bobef Wrote:
>>>
>>>> Make this syntax valid:
>>>> A.a[1]
>>>> A.a.length
>>> Why? Can you show/tell some purpose of it?
>>>
>>> Bye,
>>> bearophile
>> I think he can't have a reference to the second "a" method, because &A.a just returns the first one. So he's asking to treat "A.a" as an array of methods.
>>
>
> ouch!
>
> better solution
>
> &A.a(char[])
> &A.a(int)
>
>

cast(uint function(char[]))&A.a

already works, but is terribly unwieldy, I'll agree.

Reply to Jarrett,

> "BCS" <ao@pathlink.com> wrote in message
> 
>> ouch!
>> 
>> better solution
>> 
>> &A.a(char[])
>> &A.a(int)
> cast(uint function(char[]))&A.a
> 
> already works, but is terribly unwieldy, I'll agree.
> 

template FnWithThese(T...)
{
    R function(T) Args(R)(R function(T) fn){return fn;}
    R delegate(T) Args(R)(R delegate(T) fn){return fn;}
}

FnWithThese!(char[]).Args(&A.a)

(untested)

At least that's clearer what it's doing

bobef wrote:

> Hi, the suggestions is this:
> 
> In this case:
> 
> class A
> {
>   uint a(char[] b){}
>   int a(int b){}
> }
> 
> Make this syntax valid:
> 
> A.a[1]
> A.a.length
> etc

There's a very complicated variation of this idea and a slightly less complicated one.

The less complicated variation: The index always has to be an expression that can be easily evaluated at compile-time (like a literal or a constant). That way, every member-reference can be fully qualified at compile-time. However, if this is the behavior you want, you might as well call the members A.a1 and A.a2. I believe the D template system allows you to use a syntax like A.a!(1) and A.a!(2) in this case (though I haven't used D in quite a while, so I'm not sure). And the .length property would not be very useful in this variation.

So I'm guessing you are suggesting a more complicated variation, in which the index can be any integer expression. The problem here is that the compiler can not always know what to expect when A.a[i] is called. The function might take or return incompatible types (like char[] vs. int). Either you'd have to make sure the code at the call-site is compatible with any value of 0 <= i < length, or you'd have to guarantee that i will have a value such that the function-call is correct. This is not a condition that the compiler will be able to verify, and an error might result in very strange run-time behavior. I suppose you can work around this last problem by assert()ing a compatible state of i before the call.

But I believe that in both cases the idea is more trouble than it's worth. Can you give an example in which it might be useful?

-- 
Michiel