auto (un)boxing methods to functions and procedures

[Christian Vogel]

I saw that others have asked for method references like in Java 8, and that the answer was that there is not a good use case for them since the closure syntax usually is as good.

However it is is not possible to do higher level method operations because of this, especially if there is more than one parameter. The closure solution only works as a hack for one parameter.

For example:

// given:

class Foo {

def static hello(String greeting, String name) { println(greeting + ' ' + name) }

}

// current solution:

val formalGreeter = [ String greeting, String name | foo.hello(greeting, name) ].curry('Hello dear ')

formalGreeter.apply('John')

formalGreeter.apply('Mary')

// what would be great:

val formalGreeter = foo.bar.curry('Hello dear ') // uses autoboxing from method to type

formalGreeter('John') // "unboxing" to formatGreeter.apply('John')

formalGreeter('Mary')

[dustContributor]

I'm a big fan of method references, all of the variants:

SomeClass::staticMethod

SomeClass::new

someObject::instanceMethod

And so on. I hope there are plans to implement the same features with the same syntax in the future.

[Efftinge, Sven]

The problem with that syntax is, that it is used in Xtend to do static method invocation, too.

I.e. the declaration

class SomeClass {

   def String staticMethod() {}

}

can be called using

SomeClass::staticMethod

It's a somewhat historical thing and should be deprecated, but without target type information such an expression should still be of type

'String' rather then '()->String', otherwise such a change could potentially break existing code. 

--
You received this message because you are subscribed to the Google Groups "Xtend Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xtend-lang+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christian Vogel]

Hi Sven,

I see, both SomeClass.method and SomeClass::method can be seen as SomeClass.method().

Maybe it is a good idea to start deprecating the current :: notation in Xtend and creating compiler warnings for it. In the end you will want to be able to have at least functional parity with Java.

[Typhoon Storm]

I also feel that Xtend have quite a few legacy features, though I cannot enumerate them now... Now Xtend is version 2.9, and I suggest that a total deprecation of legacy feature be done in version 3.0( if there is not going to be version 2.10). It is understandable to make some big changes at major version upgrade.

[Efftinge, Sven]

IMHO there are not many (compared to other languages that have not even reached 1.0 ;-)) but it would certainly help to enumerate them just to make sure there is an agreement. Maybe you want to open a bugzilla and list the element you would like to see deprecated or removed in a future release.

Cheers,

Sven