variable scoped late binding

[Bill-McC]

This proposal addresses scenario #135.

In VB today we can turn Strict Off and use late binding on Object, but that impacts on the entire code file at a minimum. C# was late to the late bound party, but introduced the dynamic type modifier to allow late bound code scoped to the variable. I would like VB to introduce the same or possibly better but including duck typing. eg:

 Implicit Dim variable   ' object late bound
 or
 Implicit variable ' object late bound

And duck typed:

` Implicit variable Implies DuckInterface

`
When a variable Implies a DuckInterface, the experience is as strongly typed to the interface without having to actually be of that type.

Perhaps it could be both:

   Dim variable Implies DuckInterface  ' only allow calls as per the interface
  Implicit variable Implies DuckInterface   ' intellisense for the interface members but allow other member calls as per late bound object

[Bill-McC]

how do I label this as discussion ?

[AnthonyDGreen]

Hey Bill!

Could you give a real world example of the duck typing scenario?

Would you expect the entire interface to be validated up front?

[Bill-McC]

Hi @AnthonyDGreen ,

I've been doing stuff with the machines taking over the world (aka iot), where a lot seems to be based around json. A lot of it seems flat world without any inheritance model, and full of repetition. And some of the things have their own communication model, so it's more practical to just grab a wrapper that exposes the objects: problem being you can't change their object model unless you write a wrapper for their wrapper.

So I'd like to be able to declare a variable late bound (dynamic) to deal with the possible things, yet have intellisense experience. The duck interface would only be an intellisense thing: late bound calls

[AnthonyDGreen]

@Bill-McC ,

I LOVE this idea. Previous designs of dynamic interface proposals get stuck in a ditch around early validation and performance optimization. By focusing purely on tooling (i.e. IntelliSense) the feature becomes a lot simpler. I can also imagine some powerful capabilities when combined with other features we're discussing. Thanks a lot!

[franzalex]

@Bill-McC

I really find your proposal interesting but I think some clarification of cases will be in order.

Kindly correct me if I'm wrong.
Wouldn't the interface binding you're proposing implicitly be equivalent to casting an object to an interface using current VB code?
i.e.

Dim item As Object
CType(item, Interface1).InterfaceMethod()  ' one option
item.InterfaceMethod()  ' second option (if absolutely positive item implements Interface1)

If this is the case, then it means that by implementing the first part of your proposal (per-variable late binding), there won't be any need to implement the second suggestion of interface binding.

[Bill-McC]

@AnthonyDGreen Glad you like it. And thank you !!

@franzalex Not casting to an actual interface, rather an implied interface. eg an object might have a name, an id, a state without actually implementing some interface that defines those properties/methods. It's probably closer to CallByName in concepts, but has a tooling experience

[jrmoreno1]

@Bill-McC : do you imagine this working as a parameter type? f(Implicit x Implies IDuckInterface)? Also have you thought about operators?

[Bill-McC]

@jrmoreno1 : re parameters, might be nice but maybe add it later . I'd achieve the strict code everywhere with scoped late binding by having the parameter as an object and assign it ,eg:
f( obj As Object)
Implicit x Implies IDuckInterface = obj

re operators, don't think they'll really apply as the implicit interface moves things into strongly typed: eg x.FirstName & " " & f.LastName the concat is on String. That's the beauty of the duck interface is you deal with undefined/anonymous types via late binding but bring it straight into strong typing world.

[jrmoreno1]

@Bill-McC: the reason I mentioned parameters, is because it provides a chance for additional type safety -- if you call f with an object that doesn't meet the requirements of IDuckInterface, that is a compile time error.

As for operators, I was thinking more along the lines of Equals and numbers.

[Bill-McC]

@jrmoreno1 Not really after compile time errors as I expect these to be late bound calls (similar to dynamic in C# but with intellisense;) ). I'd want a derivative that has those member names to work.
Consider generics, eg List(Of IDuckInterface) and it gets really hard really quick especially if that has to be CLR compliant. At that level you'd need CLR support for duck typing//"implicit interface types", not just implicit interfaces.
So that's aiming at a much bigger target, and has a lot of issues to deal with. I'm just talking about having simple scoped late binding in VB with a good editing experience, and not having to turn strict off everywhere. I think if we keep it simple, then greater chance of it adapting to duck interface types, should they ever come about.

[xieguigang]

Dim variable Implies DuckInterface        ' only allow calls as per the interface
Implicit variable Implies DuckInterface   ' intellisense for the interface members but allow other member calls as per late bound object

I would more prefer using Declare keyword instead of as Implicit, as it almost keeps the same meaning with Dim variable As Type statement but produce different behavior:

' Declare for late bound
' intellisense for the interface members but allow other member calls as per late bound object
Declare variable As DuckInterface

' Dim for early bound
Dim variable As DuckInterface

[AnthonyDGreen]

The VB LDM looked at this issue on August 23rd and rejected this proposal in favor of proposal #117. In particular we didn't like that the capabilities of the value were limited to the kind of declaration you used rather than the value itself so you'd have to store things in temps to enable late-binding a lot.

[jrmoreno1]

@AnthonyDGreen : Why would you store things in temp instead of just adding to the interface being used? The DuckInterface would in most cases never be implemented, just declared (and probably only used in one method). While #117 makes it slightly easier to deal with Option Strict Off, it's not significantly better than the alternative (another file and a partial class). In particular it doesn't make the code more readable -- with a declared interface, programmers get the same benefit that IntelliSense gets -- namely that the object is expected to to have these properties and methods.

#117 doesn't really add any new capabilities to the language and doesn't make the code any easier to read or write, it could just as easily be implemented as an IDE refactor "Move method to partial class". And either way, you loose compile time type checks where you may not want to.

This proposal would make both reading and writing the code easier -- it more clearly sets expectations, both for the programmer and for the tooling (IntelliSense).

It also doesn't conflict with Option Strict Off if you must have it, I would expect this to work if Option Strict was off.

Declare variable As DuckInterface = whatever
Ctype(variable, Object).Moo

[AnthonyDGreen]

Ah, I see the problem. Our review was not about having a DuckInterface, it was about having the dynamicism be variable-scoped. The DuckInterface idea is being explored in #106 and is not mutually exclusive to #117.

[Bill-McC]

Just an observation: I'm finding the branching of work items a bit of a pain to follow. For example, if an item is broken down into parts, and each part examined it is easy to argue one leg doesn't add much more than another, but tell that to the three legged horse.
#106 isn't mutually exclusive to #117, but #136 is important for a package with #106. But if #117 is preferred to #136, then #106 looks more like that three legged race horse.
I understand the desire to break things down into work items, but would rather see task orientated concepts conversations.

[jrmoreno1]

@AnthonyDGreen: Do you mean that you'd have to have Option Strict Off to have a DuckInterface? That seems counter-intuitive.