Owwww, I like Fantom already just for the language constructs. One thing I would really like to suggest: named parameters.

First, it would be good if any fanton source would ALWAYS store the parameter name, so that we do not end up with "arg0", "arg1".

Secondly, source would be so much better readable if this:

call doit(true, false, true);

could be written as:

call doit(moveLeft=true, jumpHigh=false, theEnd=true);

Or something similar. This is just a compiler trick, which compares the parameter names to the ones know in the method definition and reorder accordingly. If there are no names available, e.g. when using a java library, then you cannot write it like this.

Brian was talking about named parameters, but not sure will it be available for fan 1.0 (that is the official fan version). It would make an interesting addition to facets which currently use with blocks for more than one parameter.

First, it would be good if any fanton source would ALWAYS store the parameter name, so that we do not end up with "arg0", "arg1".

This happens already, you can get to parameter names via reflection:

fansh> Str#replace.params
[sys::Str from, sys::Str to]
fansh> Str#replace.params[0].name
from

One thing I would really like to suggest: named parameters.

I think it is highly likely that Fantom will eventually support named parameters. But it is off the table for 1.0 due to some tricky issues with how they interact with other features such as default parameters and suffix based closures.

In general the "Fantom way" is to avoid methods with more than a couple parameters to begin with. In current code base there are just shy of 20,000 methods and only 27 have more than four parameters.

Named parameters can be converted into class. What is the disadvantage of such solution?

class HowDo{
  Bool moveLeft
  Bool jumpHigh
  Bool theEnd
}

// calling
doit(HowDo{moveLeft=true; jumpHigh=false; theEnd=true})

• boilerplate code (addition class, additional constructor call in each call)
• you are forced to call it using named parameters instead of it being optional
• strange to call by reflection
• slower
• ...

@Helium: Indeed. @Akcelisto: something similar I used in Informix 4GL, but native support is much better. Although a class has the advantage that you can add parameters without changing the interface of the method.

But as said; IMHO this is just a compiler trick. If the parameter names are available, the compiler can evaluate the parameters in the order in which they are specified in the method, since there is no construct that only evaluates half the parameter (as an || or && condition probably does).

If there are no parameter names available, then the sequence of the parameters must be the same as in the method, but the assignment can still be there for readability!