Erased interfaces

[AnthonyDGreen]

In #43 @Bill-McC suggested something pretty awesome to address scenario #135 that's been stuck in my mind. The sticking point we've had with "dynamic" interfaces/duck typing has been how to validate that the object being "casted" to has all of the required behaviors of a duck. Bill had the insight that the major benefit of duck typing isn't the error proofing but the tooling. With compile-time constraints you can get IntelliSense and other type checking. If we chuck the performance goal the feature becomes both simpler and more powerful, I think (and is it that much more dangerous than COM interop and NoPIA?).

In short, you'd declare such an interface normally but you'd be able to specify some sort of erasure pattern.

<Erased(DefaultErasure:=Erasure.MemberAccess)>
Interface IDuck
   Sub Quack()
End Interface

At design-time everything would behave as though this interface were real but during compilation the compiler would erase any use of members of the interface in some prescribed way. By default a late-bound access would be the most useful but we could also support erasing to a dictionary access to provide strongly-typed tooling over expando-objects or the XML axis properties. All the casting and stuff on the consuming side should probably be preserved.

F# has this feature called type providers where F# developers can write plugins to the compiler the generate types/objects on the fly often providing a typed view over untyped data from CSVs, databases, and web services. I think if you combined the ability to define erased interfaces with the proposed code-injectors feature you get many of the benefits of type providers without the complexity of forcing extenders to produce bound trees.

[AnthonyDGreen]

The VB LDM looked at this issue on August 23rd. This proposal wasn't a pure alternative to other proposals looked at so we can still pursue it. But it needs to be fleshed out more and maybe prototyped before looking further. One concern raised was that is repurposes the concept of Interfaces but it doesn't really behave like an interface. If you were to declare a parameter as taking one of these interfaces what would consumers see? Object? There are a lot of unanswered experience questions here.

[Bill-McC]

Hi @AnthonyDGreen ,
First off, the named "erased" : it's exposing the compiler details, an implementation detail which could change. We care not how the compiler satisfies it's binding, just care that it is done. I think "dynamic" or "implied" are more suitable style names. In VB we often hear the term "late bound" but I think that's inappropriate: it's "late" because it isn't "early" when really it is "just in time" binding// runtime queried binding ;)

As to Object, yep. It makes more sense as a package with the original proposal, where Object can be an Implicit variable (dynamic)/expando .
Maybe it might be simpler to leave parameters as Object and annotate. eg
Sub Foo(duck As Object Implies IDuck)
or
Sub Foo(duck as Object With IDuck)

[AnthonyDGreen]

Yeah, the name is a call-out to F# type providers, but agreed it's not great for marketing. C# is calling a similar proposal "shapes" and it might be worth considering something like "views" or something. The feedback from the LDM was that the term Interface might be too strong but it still may prove better than alternatives.

[Bill-McC]

I like View

[Bill-McC]

So with a view to a View, rather than something erased, if a view is a pseudo type, could it also contain code implementation ?

Say we had:

View EventRecord
    Property Intensity as Int32
    Property Hour as Byte
    Property Minute As Byte
    Property [Date] As Int16
    Function getDescription As String
    Sub setDescription As String
End View

But we really wanted Intensity as an Enum, and we wanted to combine Hour Minute and Date into a DateTime, and we wanted to map the get and sets of Description into a Property.... how cool would it be if we could put a view on that dynamic type that includes implementation ??

 View EventRecord
     Property Intensity as IntensityRank
            Get
                ...
             End Get
             Set(value as IntenistyRank)
                ...
            End Set
      End Property

     Property Record Date As Date
             Get
                ...
             End Get
             Set(value as Date)
                ...
            End Set
      End Property

     Property Description As String
            Get
                ...
             End Get
             Set(value as String)
                ...
            End Set
      End Property
End View

And this would also allow conditional mapping inside the view, but we would still be dealing with the same object reference, not creating a new object. Kind of like extension methods pumped up.

the more I look, the more I like View ;)

[Bill-McC]

Oh, and maybe Views could actually be on Types other than Object. Would be a way to group extension methods and properties.
eg

View(of T as Person) as PersonDetails
     .'extensions
End View

and in use

Dim customerView as View(of Customer) = someone

I thought generics so as the underlying type details are exposed to the level desired.

Not really sure on this last part but might be worth considering in the design so as it is not excluded in the future ?

[jrmoreno1]

@AnthonyDGreen : I would expect consumers would see an Object. I would also disagree that it doesn't behave like an Interface -- slots and vtables are implementation details there for performance and interopability reasons. Those are how they are implemented and usable across languages and assemblies, they are NOT what an interface is. That is a declaration of ability (functions, subs) and data (properties). I would expect that an Interface defined in an assembly compiled from c# code would be usable for the IDuck.

[AnthonyDGreen]

I get your point. What we meant is that an interface is a contract. If an API takes an interface it expects to be able to call members of that interface without MissingMemberExceptions being thrown. So now there are a class of interfaces which can't be used as a common currency of exchange between API authors and consumers. It may just be a case of making sure the IDE and docs and such are always transparent about the late-bound nature of said interfaces.

[jrmoreno1]

@AnthonyDGreen: I think a new keyword would cover making it clear that it is late-bound. Also (and please understand this is just a thought that occurred to me as I typed this reply), I'm not sure that Implies needs to be limited to interfaces. You could conceivable use it for an concrete type. In most cases that is probably not too beneficial (it would actually suffice in at least one case where I would like to get rid of Option Strict Off), but if you include operators, it might allow a late-bound general numeric method (adding, multiplying, comparisions, etc).

Edit: on rereading this, I had trouble coming up with the case where using a concrete type would help, so thought I would make it a bit more explicit.

Implies results in a late bound call. I have a function where one of the parameters is either of TypeA or TypeB. The types don't have a common parent and don't implement a common interface. I need to get the value of 3 properties, both types have the properties I need. With Implies I could either create an interface for the 3 properties I want and use that, or use one of the types for the same effect. An interface would be preferable as it would not be misleading, but because everything is late bound, using an actual type would suffice because it is not actually cast to the type.