I have a remark about context parameters. I am exp...

# language-evolution

[Arjan van Wieringen]

I have a remark about context parameters. I am experimenting with them and it solves quite a few DSL problems, but I also notice that it heavily reduces 'code discoverability' in autocomplete from IntelliJ. What do I mean with this?

When you have "regular" code with some dependencies like follows:

fun doFoo(depA: DependencyA, depB: DependencyB, param: Param) { ... }

you can type doF in IntelliJ and see the possible options that are available in this scope.

However, when you have context parameters you have the above example as follows:

context(depA: DependencyA, depB: DependencyB)
fun doFoo(param: Param) { ... }

you will never get doFoo as suggestion if you do not have proper contextual scope. This makes perfect sense of course! However, it greatly reduces ways to discover API's via IntelliJ, without going fully into docs / source code. I can imagine that working with foreign API's which require context parameters it is hard to find the proper functions.

Are there any ideas around this? E.g, autocomplete/hinting with suggestions that will work if you add more context?

[Alejandro Serrano.Mena]

thanks for the feedback! I'll forward this to our IntelliJ colleagues, since it seems something that can be improved there

[CLOVIS]

It's interesting, because I personally use context parameters within DSLs, and I never want people to get auto-completed DSL methods when they're not using the DSL, as that would pointlessly pollute autocomplete.

I'm not sure how IntelliJ can figure out which is which.

[Ben Woodworth]

@Arjan van Wieringen Out of curiosity, do you have examples? I know I feel this way with extension functions once in a while, but if I have an idea what the function is called (just not the specific type/sub-type), Shift, Shift and searching for the symbol can usually save me from looking through docs. Wondering if the same could help here

[CLOVIS]

@Ben Woodworth are you asking me or @Arjan van Wieringen?

[CLOVIS]

Just in case, here's an example:

users.findOne {
    User::name eq "Fred"
}

users.updateMany {
    User::age += 1
}

The methods eq and += are absolutely meaningless outside of the brackets, and it would hurt the developer experience if they appeared there, because the DSL overloads a lot of operators on very common types. Users can't easily create their own instances of the DSL, and even if they do it's very un-idiomatic. It's fully expected that the user can never use these operators outside the DSL.

Thinking about it: all my functions are annotated by an annotation itself annotated with @DslMarker . Maybe that could be the rule? If it's part of a DSL, don't autocomplete when the DSL isn't in scope?

[Ben Woodworth]

Should've clarified! But I was asking Arjan wondering what ways the problem could pop up