Hello Steven, After thinking your reply and doing more search, I found Julia support x.f(y) natively by encapsulating f into the constructor of object x. So thanks a lot!
Now I have another question: Since x.f is different for different x, f need to be compiled as many times as the number of x ?? Here I suppose f uses x. On Wednesday, October 7, 2015 at 11:03:13 PM UTC+2, Stefan Karpinski wrote: > > In this case, it also obfuscates the meaning of the code. Does x.f(y) mean > f(x,y) or is it actually x.f(y)? With this proposal you would need to know > something about x in order to decide, currently there's no confusion. > > On Wednesday, October 7, 2015, Steven G. Johnson <steve...@gmail.com > <javascript:>> wrote: > >> On Wednesday, October 7, 2015 at 1:26:00 PM UTC-4, cheng wang wrote: >>> >>> I don't see why it is bad to support more styles if there is no harm to >>> the original one. >>> >> >> Because code that mixes multiple styles is harder to read (imagine >> reading a document that jumps back and forth between different spellings), >> harder to share (because other Julia programmers won't know your >> idiosyncratic style), and harder to combine with other features of the >> language (as others have said, multiple dispatch is central to Julia's >> design and central to the design of the standard library). >> >> This comes up with every new programming language, which is why it is >> useful to learn from history. >> >
