On Sun, Jul 6, 2014 at 7:56 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Sun, Jul 6, 2014 at 2:30 PM, Matt Oliveri <[email protected]> wrote: >> Come to think of it, how does an interface differ from a full blown >> object then? > > Interfaces consist exclusively of methods. No data fields.
What you said made it sound like you effectively have at least fields of reference type: ------------ On Sun, Jul 6, 2014 at 11:38 AM, Jonathan S. Shapiro <[email protected]> wrote: > As a second example, > the "state" over which an interface closes may not be a singleton reference > to an underlying object. The encapsulated value may be a composite type > containing references to a number of objects. In some cases the interface > may perform its function by relying on multiple underlying objects. ------------ >> And correspondingly, how does the "Castable" type class >> differ from a "Coercion" type class for implicitly coercing between >> arbitrary types? > > Two names for the same thing. I may have made a mistake and swapped names > somewhere along the way. The "Castable" or "Coercion" type class says what > X's and Y's may appear in "x:X as Y". The associated type class instance > says what that expression actually means. OK, but then why would you _want_ to use interfaces instead of objects? _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
