On Thu, Jul 3, 2014 at 7:56 PM, Matt Oliveri <[email protected]> wrote:
> > The notable exception being when the effect is a strict reduction on the > > original authority. > > How is strictly reducing permissions not controlling permissions? Is > this some technical sense of "control" that I didn't pick up on? > Sorry for the confusion. It *is* controlling permissions. But if we know that we are strictly reducing permissions (as we do in an upcast), there is no need to place a guard on that operation. The party holding the higher-permission reference already has all of the permissions they will obtain through the reducing operation. This is in contrast to downcast or "fetch other interface". If we reject promiscuous use of these, then these become rights-amplifying operations. Those either need a guard, or they need to be something that we have explicitly decided to view as non-amplifying. This may be a better way to think about it: If I hold some reference, I have *permission* to perform some operations on the designated object. But I also have the ability to fetch some transitive reflexive closure of other references from that initial reference. Some because the fetch is unguarded (as in fetch field from object). Some because I happen to have the required guard in hand. So from the initial reference, my *authority* is the right to perform all operations on all objects/interfaces that are reachable in this transitive reflexive way. Sometimes, we will design a family of interfaces that all work together. We break them out either for conceptual reasons or commonality reasons, but we envision them as collectively conveying a single "block" of authority. At other times, we may want to preserve encapsulation, either for modularity reasons or for actual security reasons. > But the ones that I can actually exercise [in Java] are > > constrained by the static type through which I invoke. > > But they're not! You can downcast or reflect. That's exactly why my > way is in fact the right way to think, if you're stuck with Java. > Ah! We're hung up on the distinction between permission and authority. And I was speaking from the perspective that the presence or absence of mandated promiscuity in the language makes a difference. Since promiscuity is language-mandated in Java, what you say makes good sense. > > Yes. But in this case the implementation details make it clear that they > are > > wrappers. There are other possible implementations, but they are > > semantically equivalent to the separate VTable implementation. Which is > to > > say that all of them are semantically equivalent to wrappers. > > Yes, all of them are semantically equivalent to wrappers which > *deliberately have the same object id as the original object*. If that > is not a sign that the wrappers are meant to be ignored, I don't know > what is. > I guess I had not realized that about the object ID. So they broke EQ, and rather badly at that. BARF! I can see reasons for doing that, but the language shouldn't have mandated it. > >> I guess the question then is: Is BitC going to have a > >> notion of dynamic interface distinct from the static type? > > > > No. BitC will not. > > So why are we still talking about this? :) Is it 'cause arguing about > our area of interest is so much fun? Nah, can't be. > Because I'm trying to get clear about this myself. And consequently I need to withdraw what I said above. But BitC doesn't have vTables in the absence of interfaces (there are no virtual methods), so the question you were asking maps out in a different way. There is, of course, a set of operations that can be performed on an object, but the syntactic and typing relationship between those operations and the interfaces is different in a way that makes answering your question non-obvious. I need to write this down, but I need to get my dogs out of the house briefly first. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
