On Tue, Jul 1, 2014 at 5:27 PM, Matt Oliveri <[email protected]> wrote:
> On Tue, Jul 1, 2014 at 6:44 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > it turns out > > that the "X as Y" expression isn't syntactic sugar, because a base > > class/interface designer cannot enumerate all potential derived > > class/interface types. > > But then you can't enumerate the guard type for all potential derived > types, so it seems like the real question is again whether to use > wrapping or just an interface. (Where the latter would have checked > downcast.) Unless you meant to demand the same guard for any downcast, > which would provide some middle-ground. > One more time: wrapping *is* interfaces. If not, please explain the difference. You can actually get a lot of power out of using the same guard for every downcast, particularly if the guard is per-cast. Note that with interfaces, downcast actually isn't the correct term, because the object is not a subtype of the interface type. It's existential open. The interesting thing about the as() operator is that we can do "casts" to various different kinds of things, each having a distinct guard object type. > So for the downcast case, what I'm really proposing > > is that "x:X as Y" requires both "dynamictypeof(x) <=: Y" and also > > "X.canDownCast() = true". > > I like having a flag for whether an interface is "dynamically > abstract" or not, but is it right for that to be a method? I didn't intend that it should be a method; I was trying to illustrate the notion that some interfaces might permit open. Subsequent to that fragment we've moved on to the bigger discussion, so I think this bit isn't all that relevant at this point. Remember that I'm embedding the guard test in the type check, not in a call. > Why on > earth would you want that to be determined at runtime? Well, actually, there's a very *good* reason to do that: it lets you do object-specific guards.... shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
