On Wed, Jul 2, 2014 at 3:31 PM, Jonathan S. Shapiro <[email protected]> wrote: > 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.
Oh right, sorry. But I don't think Java-style downcast should be considered promiscuous, since it's not unwrapping. Trying to control authority with types while the object id stays the same still seems like a confusing can of worms. It could be a necessary can of worms though, for performance reasons, but I understand that that's not what you're currently proposing. > The thing that I think is a universally bad idea is having someone else > force me to be promiscuous. I agree, but I don't think forcing a programmer to be promiscuous is as easy as you think. Encouraging programmers not to be promiscuous is different. But here, I think the key is just for everyone to be thinking about the language's encapsulation mechanisms the right way, and to know when to use which. That may be asking a lot though. > 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. Right... > 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. OK. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
