restrict use of fluent to specified methods

[thigg]

To avoid transforming login(String,String) into an extension of String, it would be nice if this could be limited to only transform methods to an Extension, which do have a specific annotation.

This feature could be optional, although I would always enable it, I think...

[rogerkeays]

Fluent only transforms object method calls to static method calls, not the other way around. Your static login(String, String) method call will never be transformed. I think what you are saying is you want to prevent developers from using String.login(String) ? Note also, only method calls are transformed, not method declarations.

[thigg]

Yes sorry for my unclear wording here.
Lets say I have a

public static void log(String msg)

in my codebase.
The plugin does now transform a call on String::log to this method if it is in scope.
I would prefer to be able to opt-in only here. Especially if ide support becomes a thing.
I can also see, that this implies, that I can not simply do a .assertEquals("abc") anymore easily. But maybe there would be ways to work around that.

I currently see 3 benefits in making it explicit with annotations:

• the annotation is also documentation about the intended use of the method
• the annotation prevents accidental use
• the annotation keeps the scope clean to make method suggestions in IDEs more useful

[rogerkeays]

Okay, I broadened the scope of this issue a bit so we aren't constrained to annotations. My prototype for Fluent actually only transformed calls to methods ending in "EX", (e.g. "hello".duplicateEX()"). This was very simple, but didn't quite satisfy me.

Lombok and Manifold use annotations, Kotlin has a different syntax for declaring extensions methods (fun String.duplicate() {...}), and C# requires a this modifier on the first parameter of the method declaration. D, on the other hand, uses uniform function call syntax, which allows any function to be called in a fluent style.

I think if Fluent were to add annotations, it would lose it's point of difference from Lombok and Manifold. Mostly, those annotations are for the IDE, anyway. Annotations would also mean you can't use anything from commons StringUtils (for example) as an extension method.

If we were to add new syntax, another option would be import extension org.apache.commons.StringUtils.* instead of import static. As it is, we basically assume anything you import static is an extension method. So maybe we need a way to disable extensions rather than enable them, as you suggested.

Personally, I'm okay with uniform function call syntax. It makes an IDE plugin more problematic, but I don't think we should be coding for our IDEs. For now, we also want to make minimal changes to the compiler so patching future versions is easier.