• bobef <bobef nosmap-abv.bg> Aug 11 2008
• bearophile <bearophileHUGS lycos.com> Aug 11 2008
• Ary Borenszweig <ary esperanto.org.ar> Aug 11 2008
• BCS <ao pathlink.com> Aug 11 2008
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Aug 11 2008
• BCS <ao pathlink.com> Aug 12 2008
• "Koroskin Denis" <2korden gmail.com> Aug 11 2008
• Michiel Helvensteijn <nomail please.com> Aug 12 2008

bobef <bobef nosmap-abv.bg> writes:

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

bearophile <bearophileHUGS lycos.com> writes:

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


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

Bye,
bearophile

Ary Borenszweig <ary esperanto.org.ar> writes:

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.

BCS <ao pathlink.com> writes:

Reply to Ary,

 bearophile a écrit :
 
 bobef Wrote:
 
 Make this syntax valid:
 A.a[1]
 A.a.length


 
 Bye,
 bearophile


 &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)

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"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



 Bye,
 bearophile


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

BCS <ao pathlink.com> writes:

Reply to Jarrett,

 "BCS" <ao pathlink.com> wrote in message
 
 ouch!
 
 better solution
 
 &A.a(char[])
 &A.a(int)


 
 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

"Koroskin Denis" <2korden gmail.com> writes:

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


  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?

Michiel Helvensteijn <nomail please.com> writes:

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