Improve "using" (extension methods) autocompletion

[soywiz]

Now extension methods display the first argument and that is wrong.

Also would be great to be able to mark some classes with an optional annotation specifying they are classes with extension methods. That way we would be able to autocomplete those methods (but displaying them as grey and with very low priority if not having an using clause) and when as when adding import clauses, add an using clause.

I would suggest the @extension or @:extension meta:

@extension class ExtraStringMethods {
    static public function ucfirst(str:String):String {
        return str.substr(0, 1).toUpperCase() + str.substr(1).toLowerCase();
    }
}

All clases with the @extension meta would be available grayed without the using clause+action adding the using, and normal with the using clause after the indexing phase.

[EBatTiVo]

The folks who make the compiler do not watch this repo closely. If you want to propose adding the metadata tags, you might want to try the haxe compiler repo.

The resolver needs to be extended to recognize static extensions (among some other things). Otherwise, we may be able to show them in the completion lists, but they will be marked as unresolved/missing fields after they are inserted (as they are now).

[EBatTiVo]

BTW, every static method with at least one argument on any type can be used as a static extension by virtue of the first parameter type. I'm not sure what the @extension meta buys you, here. How does it make the completion code any easier?

[soywiz]

Is that it is just a suggestion not required at all for compiling. At least for the intelliJ plugin, that could be used for other IDEs including the --display.

The meta is to enable completions without adding explicitly an "using" clause. Without the metadata, it would be slow and displaying zillions of static public methods that probably are not meant to be used as extensions. With the metadata, it should be faster limiting the classes you are searching and would avoid suggesting lots of garbage.

[EBatTiVo]

The documentation for static extensions says explicitly that they are brought into scope by the using keyword. It gives no other method. Or are you envisioning that the IDE should include any potential static extension and add the keyword automatically, so the user doesn't have to specify it? That makes some sense, and it does make the problem larger. However, I think that the resultant set is fairly small because it is limited by the type of the first parameter -- we can use FindUsages to limit the search scope for static functions. Or maybe we can (and we probably should) write some better indexing than the default word-based one that is currently in use.

[sganapavarapu1]

@soywiz, Like @EBatTiVo suggested - you may want to start a thread on https://github.com/HaxeFoundation/haxe and refer this issue in that thread. You may want to call out @Simn (Simon Krajewski)'s attention for his comments on compiler specific extensions being discussed.

[Simn]

This doesn't seem to be about the compiler itself though. From what I gather he wants to mark some methods as @extension so the IDE keeps track of them, then suggests them as field access completion and, if selected, automatically inserts the using declaration.

Note: Metadata without a leading colon are passed to the run-time, so you might want to use @:extension instead.

[soywiz]

Yep. As Simn says, the suggestion was for editing time. Sometimes I fail to express my self in english. Though the idea was to annotate classes instead of methods (since the using is for classes and maybe it is a bit strange to add using for some classes that are not meant for that).

Yet it would be great for the standard library to mark StringTools, Lambda and so on with @:extensions in the case you like the idea, but just as a suggestion for editors and not having repercussion over the compiler itself.

That would improve a lot the experience specially for people without knowledge about the core api, since they would discover more methods instead of using them statically or trying to reimplement them. And probably won't know which classes are extensions and that they have to put a using clause.

In C# you have to mark the class as static + add this keyword to the first parameter. https://msdn.microsoft.com/en-us//library/bb383977.aspx#code-snippet-2

In swift you have a whole extension keyword that extends a class and even can implement new protocols/interfaces: https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Extensions.html

So if you like the idea, in my branch I have already fixed the first part of the issue: extensions methods were showing the first parameter wrongly. And I think I could work on the annotation part too.

[EBatTiVo]

Now extension methods display the first argument and that is wrong.

Also would be great to be able to mark some classes with an optional annotation...

Rereading the problem description, there are two things described in this bug:
1) A bug: Completions for static extensions still show the first argument, when they shouldn't. 2) An enhancement: marking extensions so that the editor doesn't have to do as much work to figure it out.

One of these should be split out into another issue report -- probably the bug portion, since most of the discussion so far is about the enhancement.

That said, Carlos may have already fixed the bug in his huge change #297. So, I'll wait for him to comment.

[mayakwd]

Need to recheck this issue