At Thu, 27 Apr 2006 14:42:41 +0200, Pierre THIERRY <[EMAIL PROTECTED]> wrote: > > Scribit Marcus Brinkmann dies 27/04/2006 hora 14:24: > > However, more importantly, I don't know what you mean by wrapper > > object. We want to limit ourselves to single inheritence. > > I think I was thinking to something that cannot be achieved with single > inheritance, in fact... That is, an object that could mutate its > interface to add (or remove) methods when it is brougth the associated > capabilities. I think this isn't possible in Coyotos, is it?
In fact, this is how permissions are implemented. We create one wrapper object for each object+permission bit combination. From the protected payload in the wrapper object, we determine the object ID and the permission bits. > > This works, but could easily result in a management nightmare. You > > would have to keep track of up to N capabilities for each "actual" > > capability you are interested in. > > I'm not sure. How many times in a classical software are you needing two > or more access modes to something? Saving a file ony needs write access. > Opening only needs read, and maybe probing that write is possible > (because the user could arguably want to save the modifications made > later). Launching an application only needs execution. And so on. > > Debugging would probably need both read and execution. Do you see other > cases? > > In fact, that would just make cleaner programming easier. > > > Delegation would then be simple of course: You just select the desired > > capabilties from the set. > > That's one obvious benefit, yes. > > > I have considered that before, storing a read and/or write capability > > in each directory slot. > > > > It's worth thinking about, if only to see what can break :) > > I'm not sure anything breaks, so let's try to find something. Well, say you have two capabilities per file in a directory, one for read and one for write access. Then over time, due to bugs or other misbehaviours, they could become out of sync: They could refer to totally different objects. But everybody will assume they will refer to the same object. So, we are introducing a new class of possible bugs. I agree with you that one would have to look carefully at the possible use cases. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
