On Mon, Jan 6, 2014 at 4:31 AM, Jonathan S. Shapiro <[email protected]>wrote:
> On Sat, Jan 4, 2014 at 5:57 PM, Ben Kloosterman <[email protected]>wrote: > >> Speaking of confusion if you keep HasField, then i would have a seperate >> HasMethod . Keeping it seperate makes it very clear when your using a >> method vs a delegate field. >> > > I'm still not clear what you mean by a delegate field. But from a typing > perspective what you propose is wrong. A method is simply a field having > method type. > Its a bit confusing because a field can hold a function pointer (delegate) vs a method , both can be invoked , its obvious when you need a "this" but less so for pure functions . > > The one that's more interesting is has-static-method, because that one is > not just sugar. > Doesnt that overlap with a type class ? Its like a 1 function convenience type class , how is that not sugar ? > > >> Should HasField be removed from the user and subsumed by interfaces ? >> > > It can't be, because HAS-FIELD describes cases that interfaces do not, and > interfaces are potentially matched by HAS-FIELD. > Yes interfaces are likely built on HasField but that doesnt need to mean a programmer can use it . What set of uses of HasField can be done by interfaces ? Im asking because it reduces the when to use type class and when to use interfaces question. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
