On struct/union declarations with "implements" clauses: are you thinking these would just be asserting that the struct/union implements an interface, or would you also require that the "implements" clause be there in order to implement the interface?
The assertion is definitely useful. Requiring it is vexing: in that world, if a library author doesn't state that their type implements some interface, there's no testing seam; library consumers who want to mock or fake the library type need to add a separate forwarding wrapper type which does implement some mockable / fakeable interface. I run into this in Java and C++ more often than I'd like. The ability to post-hoc add an interface to an existing type is one of the very nice features of Go, although it does complicate the implementation: you either need to statically link and generate all possible vTables, or you need to be able to dynamically generate appropriate vTables. Also: are you thinking that only structs & unions would support interfaces? )Rob On Fri, Jul 4, 2014 at 1:33 PM, Jonathan S. Shapiro <[email protected]> wrote: > Just so we're all on the same page, here is the notion of interfaces that > I plan to implement for BitC: > > An interface type consists of a set of named method signatures. Each > method has some set of argument types 'a ... 'z and a result type 'result. > This describes the "outer" perspective on an interface. > > The "inner" view of the interface is that an interface object contains an > existentially encapsulating state pointer having type 'state, and a vTable > pointer. The vTable is a table of procedure references. For each method > named in the interface type declaration having type 'a...'z -> 'result, > there is a corresponding implementation function having type 'state 'a ... > 'z -> 'result. Calling a method at an interface has the effect of calling > the implementing procedure with the additional 'state argument. > > Interface construction proceeds in the usual way for value constructors > generally. The first argument to the constructor has type 'state, and the > remaining arguments are the implementing procedures. The type constructor > differs from the value constructor in that it omits the 'state type > argument. > > > So that's the core of it. It is unclear to me whether it is useful to add > an "implements" clause to struct/union declarations. It seems like > potentially useful sugaring, but I think it needs a usage experiment. > > > Regarding syntactic support for "X as Y", I think that is determined by a > two variable type class Castable. Some instances of this type class are > implicitly populated by the compiler in the same way that CopyCompatible > gets populated. > > > So then we have the inheritance discussion... > > > shap > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
