On Sat, Jan 4, 2014 at 12:24 PM, Jonathan S. Shapiro <[email protected]>wrote:
> I'm beginning to suspect that I still don't understand the pivotal
> differences between Traits and Interfaces. In particular, I think the
> requires/provides idea in Traits isn't the crux of it. I'm beginning to
> suspect that the more interesting part is the explicit binding that Traits
> assumes.
>
> Rather than debate labels, let me say what I envision for Interfaces in
> BitC. If it turns out that this maps to Traits, I'll be happy to rename.
>
> An interface definition defines a type. Instances of this type consist of
> an (existential) managed pointer to some value (which may be a value type
> or a reference type) and set of named method bindings, each of the form 'a
> ... 'z -> 'result. The invocation of a method "opens" the existential type
> and passed the managed pointer as an additional leading parameter.
>
> We clearly want a convenience syntax for default implementations, but from
> a "core" perspective an Interface defines a class whose member types and
> constructor arguments are constrained. In particular, the actual parameters
> that bind the methods of the interface are constrained to be compile-time
> evaluable expressions. This means, in practice, that:
>
> - The method table can be implemented as a quasi-statically generated
> compile-time constant, but
> - Multiple variants of an interface can be produced for a single
> object.
> - When the underlying object type is known at static compile time, the
> compiler can elide the indirect dispatch of the interface mechanism,
> - To some degree, interface implementations can act as type relation
> witnesses in a similar way to type class implementations, and
> - An interface consisting entirely of *static* methods (that is:
> methods lacking a /this/ parameter) requires no /this/ pointer, and is very
> similar to a type class declaration. In contrast to type classes, which are
> type relations, an interface is a type.
>
> I have a suspicion that the parallels between interfaces and type classes
> may grow as we examine the implications of this definition. The difference,
> I predict, will turn out to center around operator overload resolution
> rather than types.
>
Under discussion .. anyway it looks like the "this" captures the
existential/emcapsulation and when you dont have it then an interface of
statics is a type class. Possibly this may mean we could use something
like iface with all statics as the notation for type class which may result
in easier migration for some people ( this needs a lot more thought) .
>
> Syntactic sugar: an object can be declared as "implements IFace", and the
> construction will be automatically be produced by name matching for
> convenience. But this is merely convenience. An object can also declare an
> interface generator in a style similar to attributes:
>
> interface ReverseOrdering { return OrdInterface(this, >); }
>
> Note that this quasi-attribute is compile-time evaluable. Note also that
> this "interface attribute" need not appear within an object. A global
> attribute of the form:
>
> interface YetAnotherOrdering('type ob) { return OrdInterface(t, >); }
>
> is perfectly valid.
>
> Instances of interfaces are objects. This is necessary even for purely
> static interface types because bindings are explicit.
>
> An instance of an interface may not outlive the object that it references.
>
>
> I'm sure there are half a dozen things I have omitted here, but this is at
> least a starting point for discussion.
>
This is all good..
let me start static members of interfaces have never been discussed because
they make no sense because the interface type is never used.
- There is a this method which is unused
- There are no constraints .Its the constraints or type relations that give
it meaning.
There are a lot of new programmers who ask for this.
Onto interfaces , the above are interfaces (except for static methods) not
traits . Im no expert on traits i have only done a week in Scala and Rust
which use them.
A trait is an interface with a method .. not static an instance methods.
If you view an interface as an object with some methods eg
class IEnumerable { private object collection; Enumerator
GetEnumerator( ) { return collection.GetEnumerator() }
}
than a trait would be
class ICollection { private Collection collection; Enumerator
GetEnumerator( ) { return collection.GetEnumerator()
public void Clear() { while collection.Count != collection.Remove() ; }
// as opposed to calling collection.Clear()
}
}
eg it adds type methods like inheritance.. and for the same reasons as
inheritance id rather not have them . Yes they are usefull in a small use
case but passing in common implimentations into objects is far superior at
a small perf cost and it keeps the code simpler. Type class with
constraints should be enough .
Ben
Ben
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
