dynamic classes and duck typing

[Steven Schveighoffer]

Bill Baxter Wrote:

> On Tue, Dec 1, 2009 at 4:22 PM, Steven Schveighoffer
> <schveiguy at yahoo.com> wrote:
> > Bill Baxter Wrote:
> >
> >> Good counterpoints to my argument.  So I give up on that line.
> >>
> >> Here's another, how do you implement the opBinary_r operators with opDispatch?
> >
> > Kinda cooky, but what about this:
> >
> > a + b -> b.opDispatch!("r+" )(a)
> 
> That's what I had in mind too, so I guess it's not so hard to guess.
> Really the _r convention is also kooky.  We're just more used to that.
>  So this isn't really a strong argument for separating opBinary out of
> opDispatch.

Another argument for at least keeping opBinary and opBinary_r to be defined by the same function -- commutative operators can be defined once:

T opDispatch(string s)(T x) if(s == "+" || s == "r+") { return T(this.val + x.val);}

> 
> But that is part of why I was asking about opIn -- if opIn_r's
> spelling remains "opIn_r" then we will have both conventions to deal
> with.  Not so good.  But if that one's changing to opDispatch!"in"
> also, then we'll need opSomething!"rin".  Which is kookier than "r+",
> I think, but at least maintains consistency.
> 
> But there is a problem.  It means you can't opDispatch on a method called "rin".
> So I think there would have to be some non-symbol char in the "r"
> prefix used.  Maybe "r:+", "r:+=", "r:in".  Or just a space -- "r +",
> "r in", ... etc.
> But now it's a notch less intuitive.

opIn is definitely a weird one.  Normally, you only want to define the reverse version.  Like you said, you can't use "rin" because rin isn't a keyword.

I think we can probably come up with a non-symbol representation to denote "Reverse" that's intuitive or at least memorable enough.

other ideas to ponder:

"op.r"  (no need for ..r because opDot doesn't have a reverse version)
"op this" denoting that 'this' is on the right hand side

-Steve