Lightweight interface implementation

[isaacabraham]

Currently if you have VFPT implement an interface, you get a fully-typed, verbose implementation e.g.

let processor = {
    new IEventProcessor with
        member __.CloseAsync(context: PartitionContext, reason: CloseReason): System.Threading.Tasks.Task = 
            failwith "Not implemented yet"

        member __.OpenAsync(context: PartitionContext): System.Threading.Tasks.Task = 
            failwith "Not implemented yet"

        member __.ProcessEventsAsync(context: PartitionContext, messages: System.Collections.Generic.IEnumerable<EventData>): System.Threading.Tasks.Task = 
            failwith "Not implemented yet"
}

I will almost always simplify the above to: -

let processor = {
    new IEventProcessor with
        member __.CloseAsync(context, reason) = failwith "Not implemented yet"        
        member __.OpenAsync context = failwith "Not implemented yet"        
        member __.ProcessEventsAsync(context, messages) = failwith "Not implemented yet"
    }

I know that might not be everyone's cup of tea, but an option to have this would be nice. Even a halfway house that didn't use fully-qualified namespaces but added open statements would be good.

[dungpa]

Nice idea.

AFAIR we chose to add type annotations because type inference on interfaces is too brittle. The type checker can't distinguish between overloads without complete type annotations.

It occurs really often for interfaces from BCL. You can try removing annotations from interface implementation of those inherited from ICollection & ICollection<'T> or IEnumerable & IEnumerable<'T> to reproduce the problem.

[dsyme]

How about giving the annotation-free version if no overloads are involved (or if overloading is only by argument count)? For those cases the inference is robust.

Or offer two options - one annotated and one not?

[isaacabraham]

I think having both options is preferable - can be shown as two options in the light bulb help.

[dungpa]

I think either approach (mixed typed annotations vs two commands) would make great improvement here.

This is a localized change which is ideal for community contribution.

Here is how it can be done:

• Add a boolean argument to formatInterface https://github.com/fsprojects/VisualFSharpPowerTools/blob/e736aa38668d182696b04dd2f6e6dd637b2515f1/src/FSharpVSPowerTools.Core/InterfaceStubGenerator.fs#L481
• The most important function already has hasTypeAnnotation argument https://github.com/fsprojects/VisualFSharpPowerTools/blob/e736aa38668d182696b04dd2f6e6dd637b2515f1/src/FSharpVSPowerTools.Core/InterfaceStubGenerator.fs#L138
• Add another command similar to this https://github.com/fsprojects/VisualFSharpPowerTools/blob/e736aa38668d182696b04dd2f6e6dd637b2515f1/src/FSharpVSPowerTools.Logic/ImplementInterfaceSmartTagger.fs#L132-L149

Is there anyone up for doing this?

[isaacabraham]

I could give it a bash :-) Do you give out F# cups as well for first-time contributions? :-)

[dungpa]

Good idea. If only I knew how to make those cool cups :-)...

(Let me know if you need any assistance in implementing this.)

[isaacabraham]

@dungpa: I will :-) WIP as of now.

[isaacabraham]

• Get things building locally
• Get arguments to show without types
• Hide return type for methods
• Hide return types for get/set properties
• Hide return types for getter properties
• Stub implementation on same line
• Hide newline
• Show second suggestion in lightbulb
• Handle overloaded members

[isaacabraham]

What should we do if the user selects the lightweight syntax on a type that won't compile under these circumstances e.g. System.Collections.IDictionary?

1. Do nothing - they can fix it manually.
2. Be extra smart and choose explicit types just for those members (how do we determine this?)
3. Don't show lightweight implementations (ditto).

[isaacabraham]

This is what the non-verbose version of e.g. IDictionary looks like. Obviously this code doesn't work (precisely because of the reason originally mentioned) - still looks reasonably clean though.

[dungpa]

Looks good.

I think 2nd option (choosing explicit types for those members) is a good tradeoff. It's actually a small change from what you got.

• We already sorted members by names https://github.com/fsprojects/VisualFSharpPowerTools/blob/e736aa38668d182696b04dd2f6e6dd637b2515f1/src/FSharpVSPowerTools.Core/InterfaceStubGenerator.fs#L550-L553
• For any pair of consecutive members in the sorted order, add type annotation to the latter member if they have the same name and have the same argument count.
• To add another suggestion to the list, add another command here https://github.com/fsprojects/VisualFSharpPowerTools/blob/e736aa38668d182696b04dd2f6e6dd637b2515f1/src/FSharpVSPowerTools.Core/InterfaceStubGenerator.fs#L550-L553. Perhaps rename the function to getSuggestions?

[dungpa]

@isaacabraham How is it going with ImplementInterface enhancement?

[isaacabraham]

I haven't had a chance to do that much more on it. You can see the code that I've committed in my fork - I think that there's still a bit of work to do with indexers, and I'm seeing some wrong behaviour when implementing interfaces as an object expression (the braces don't align).