On Wed, Jul 2, 2014 at 12:08 PM, Matt Oliveri <[email protected]> wrote:
> > Note that with interfaces, downcast actually isn't the correct term, > because > > the object is not a subtype of the interface type. > > I agree. You threw me off by calling it a downcast. You seem to think > unconstrained downcast is universally a bad idea, but I don't, so it's > important to me not to confuse downcast and unwrapping. > I apologize for the confusion. I do not believe that unconstrained downcast is universally a bad idea. What I believe is that it's a decision that shouldn't be imposed by the language definition. If downcast had not been promiscuously permitted, subclassing might have been a very useful mechanism for certain security patterns. Similarly, if unwrapping had not promiscuously permitter, interfaces might have been similarly useful. The thing that I think is a universally bad idea is having someone else force me to be promiscuous. And if that's not my quote of the day for today, I'm not sure what will be. :-) > > > Remember that I'm embedding the guard test in the > > type check, not in a call. > > Oh, _only_ the type check, OK. But wait, then how does this help with > unsealing, which generally entails a runtime test? By pushing the criteria into the type check, I'm hoisting the test to compile time. Basically, you can open an existential wrapper if you hold an object of the corresponding key type. The rest is built on constraining the propagation of key objects. If you need to do instance-specific checks, you can stick the key in a closure and implement a more complicated unlocking rule as needed. You won't get to use that in an X as Y expression, but I don't see that as a big impediment. Frankly, I think that the most common use of this in practice will be simply to allow or disallow existential open. More interesting uses will be rare. Which is good, because security patterns work best if you can whittle them down to a small number of building blocks. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
