Bill Baxter Wrote:
> On Tue, Dec 1, 2009 at 4:22 PM, Steven Schveighoffer
> <schvei...@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
