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? It would still be possible with a dir object, from which one acquire the specific capabilities, but this is maybe far too overhead, and manipulating individual capabilities is maybe easier (or maybe not). > 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. Curiously, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
