On Tue, Jul 1, 2014 at 6:10 PM, Jonathan S. Shapiro <[email protected]> wrote: > I'm proposing something sneakier than that, because the guard requirement > can be made by design to be something promiscuous like unit. That has the > same effect as enabling promiscuous downcast.
Yup. Got that. I didn't say the token object reference had to be unforgeable or secret. > But interfaces ARE wrappers! That's the point! Ah. I forgot you're using some fancier version of interfaces than Java. But even so, they're not regular wrappers since they share the object id of the thing they wrap, or so I thought. So conceptually you're dealing with the same object after the downcast. So it still seems like under your proposal, capabilities effectively become (static type, object) pairs. Maybe that's the right way to do it with a strong type system, but maybe not. > There is a chicken and egg problem here. The reason we don't consider these > operations to be authority enhancing is that the authority to cast is > unconstrained in the language design. Yeah, that's what I was getting at. Plus that in dynamically checked languages like E, you don't even have/get to downcast, so there's no option of attenuating authority just by changing the type. Many people think of static types as convenience and performance improvements for a dynamic language. Java is compatible with that (limiting) point of view. If BitC is not, it could be perceived as too theoretical, unless you put a lot of effort into reeducating regular programmers about what strong typing is really about, and convince them it has enough escape hatches to not be crippled. > What I'm saying is that downcast is a de-encapsulating operation, and > de-encapsulating operations shouldn't be forced on the designer of the > object. That point of view would make type theorists very happy, but again, I don't think it's the point of view of most programmers. Changing the type isn't actually changing the thing, conceptually, so downcast is just a workaround for missing static information. They are both perfectly self-consistent language designs. I don't yet see what the additional complexity of your proposal provides for the programmer. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
