Open javierfernandes opened 9 years ago
@npasserini @tesonep what do you think ? Similar to scala convention on the apply() method (only that in scala you define it as part of the companion object)
Maybe this could also be related to object deconstruction (for pattern matching), which is also a feature that I would like to have eventually.
I like this idea. It provides more clear code and it is interesting for objects that are command like.
It is nice, but it would be nice to be able to disable it. I think that when teaching the initial steps it is nice to find patterns. In wollok the usual pattern is that always you write "object.message".
Yes, Wollok already does not respect that "always", but I think we should be conservative about breaking that kind of rules. Maybe making them configurable (if possible) gives us a little of a compromise between expressiveness and regularity.
Nice ! you mean not only use it for "apply" but for any objects which has a single methods ? Kind of the way xtend allows you to pass closures in place of a java interface with a single method
object miPredicate {
method complies(something) { .... }
}
miPredicate(pepita)
Or with more parameters
object miCommand {
method perform() { .... }
}
miCommand(pepita)
Yes, for sure I would first show the idea that a closure is an object, and that once can execute it by sending a message to it.
This is more like an advance feature with syntax sugar
The idea is to have a special syntax for applying a function (a closure).
Currently you need to call the "apply()" method explicitly. This is good because it shows the fact that closures are still objects and they have behaviour. But once one realises that, then it's something visually annoying to send that message. It would be shorter to have a way to execute the closure directly.
This
would become:
Similar to a method call. Since our grammar won't allow you to send messages to this without explicitly specify "this" (the target object), there shouldn't be any conflict on the grammar.