Re: [fonc] Tension between meta-object protocol and encapsulation
Top-post: thanks for your reply. I'll check this stuff out. Somehow I missed this when you sent it. Casey On Sep 7, 2011, at 1:50 PM, David Barbour dmbarb...@gmail.com wrote: On Wed, Sep 7, 2011 at 12:48 PM, Casey Ransberger casey.obrie...@gmail.com wrote: It seems to me that there is tension here, forces pulling in orthogonal directions. In systems which include a MOP, it seems as though encapsulation is sort of hosed at will. Certainly I'm not arguing against the MOP, it's one of the most powerful ideas in programming. For some things, it seems absolutely necessary, but then... there's the abuse of the MOP. Is this tension irreconcilable? There are patterns for meta-object protocol that protect encapsulation (and security). Gilad Bracha discusses capability-secure reflection and MOP by use of 'Mirrors' [1][2]. The basic idea with mirrors is that the authority to reflect on an object can be kept separate from the authority to otherwise interact with the object - access to the MOP is not universal. Maude's reflective towers [3] - which I feel are better described as 'towers of interpreters' - are also a secure basis. Any given interpreter is constrained to the parts of the model it is interpreting. By extending the interpreter model, developers are able to achieve ad-hoc extensions similar to a MOP. These two classes of mechanisms are actually quite orthogonal, and can be used together. For example, developers can provide frameworks or interpreters in a library, and each interpreter 'instance' can easily export a set of mirror capabilities (which may then be fed to the application as arguments). [1] Mirrors: Design Principles for Meta-level Facilities of Object-Oriented Programming Language. Gilad Bracha and David Ungar. http://bracha.org/mirrors.pdf [2] The Newspeak Programming Platform. http://bracha.org/newspeak.pdf (sections 3,4). [3] Maude Manual Chapter 11: Reflection, Metalevel Computation, and Strategies. http://maude.cs.uiuc.edu/maude2-manual/html/maude-manualch11.html We can use power responsibly. The trick is to control who holds it, so that power is isolated to the 'responsible' regions of code. Regards, Dave ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Tension between meta-object protocol and encapsulation
We've already discussed this in other contexts. This is what I meant when I talked about levels of meta and why invoking a function is more benign than using a global assignment (which is tantamount to redefining a function under program control), etc. And certainly to allow unprotected rewiring under program control without possible worlds reasoning makes a very fragile system indeed (and so many of them out there are). Generally speaking, the amount and depth of required design increases greatly as one traverses into meta. (And just who should be doing the designs at each level will (should) become a narrower more expert group.) One of the interesting metafences that has been discussed in STEPS (and it would be great to move from talk to some examples) is the enforced separation of meaning from optimization. If they are in different worlds (where any and all of the optimizations could be turned off and the system would still run) then this sideways augmentation can be hugely useful and still very safe. The MOP example in the book could be considered to be one of these, but the book omitted this set of ideas. Still, you could imagine setting things up so that the new variant would be automatically checked by running the meaning in parallel, and this would make everything much less fragile. I think there is real gold here if these sets of domains and fences could be worked out. Cheers, Alan From: Casey Ransberger casey.obrie...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Wednesday, September 7, 2011 12:48 PM Subject: [fonc] Tension between meta-object protocol and encapsulation This has been bugging me for awhile. This seems like the best forum to ask about it. With great power comes great responsibility. This quotation is hard to pin down. There are several versions of it to be found. This particular phrasing of the statement probably belongs to Stan Lee, but I think the phrase, in another form, is older than that. It seems to me that there is tension here, forces pulling in orthogonal directions. In systems which include a MOP, it seems as though encapsulation is sort of hosed at will. Certainly I'm not arguing against the MOP, it's one of the most powerful ideas in programming. For some things, it seems absolutely necessary, but then... there's the abuse of the MOP. I've done it to spectacular effect :D and when one is under constant pressure to ship, one tends to reach for the longest lever in the room. On one hand, I can avoid writing a lot of code at times this way, but on the other hand, what I've done is liable to confuse the hell out of whatever poor bastard is maintaining my code now. I've also had to wade through some very confusing code that also did it. You know, as long as it's me doing it, it's fine, but there's only one of me, and there's in the neighborhood of 6,775,235,700 of you! Is this tension irreconcilable? -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Tension between meta-object protocol and encapsulation
On Wed, Sep 7, 2011 at 12:48 PM, Casey Ransberger casey.obrie...@gmail.comwrote: It seems to me that there is tension here, forces pulling in orthogonal directions. In systems which include a MOP, it seems as though encapsulation is sort of hosed at will. Certainly I'm not arguing against the MOP, it's one of the most powerful ideas in programming. For some things, it seems absolutely necessary, but then... there's the abuse of the MOP. Is this tension irreconcilable? There are patterns for meta-object protocol that protect encapsulation (and security). Gilad Bracha discusses capability-secure reflection and MOP by use of 'Mirrors' [1][2]. The basic idea with mirrors is that the authority to reflect on an object can be kept separate from the authority to otherwise interact with the object - access to the MOP is not universal. Maude's reflective towers [3] - which I feel are better described as 'towers of interpreters' - are also a secure basis. Any given interpreter is constrained to the parts of the model it is interpreting. By extending the interpreter model, developers are able to achieve ad-hoc extensions similar to a MOP. These two classes of mechanisms are actually quite orthogonal, and can be used together. For example, developers can provide frameworks or interpreters in a library, and each interpreter 'instance' can easily export a set of mirror capabilities (which may then be fed to the application as arguments). [1] Mirrors: Design Principles for Meta-level Facilities of Object-Oriented Programming Language. Gilad Bracha and David Ungar. http://bracha.org/mirrors.pdf [2] The Newspeak Programming Platform. http://bracha.org/newspeak.pdf (sections 3,4). [3] Maude Manual Chapter 11: Reflection, Metalevel Computation, and Strategies. http://maude.cs.uiuc.edu/maude2-manual/html/maude-manualch11.html We can use power responsibly. The trick is to control who holds it, so that power is isolated to the 'responsible' regions of code. Regards, Dave ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Tension between meta-object protocol and encapsulation
Yep. Cheers, Alan From: David Barbour dmbarb...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Wednesday, September 7, 2011 1:50 PM Subject: Re: [fonc] Tension between meta-object protocol and encapsulation On Wed, Sep 7, 2011 at 12:48 PM, Casey Ransberger casey.obrie...@gmail.com wrote: It seems to me that there is tension here, forces pulling in orthogonal directions. In systems which include a MOP, it seems as though encapsulation is sort of hosed at will. Certainly I'm not arguing against the MOP, it's one of the most powerful ideas in programming. For some things, it seems absolutely necessary, but then... there's the abuse of the MOP. Is this tension irreconcilable? There are patterns for meta-object protocol that protect encapsulation (and security). Gilad Bracha discusses capability-secure reflection and MOP by use of 'Mirrors' [1][2]. The basic idea with mirrors is that the authority to reflect on an object can be kept separate from the authority to otherwise interact with the object - access to the MOP is not universal. Maude's reflective towers [3] - which I feel are better described as 'towers of interpreters' - are also a secure basis. Any given interpreter is constrained to the parts of the model it is interpreting. By extending the interpreter model, developers are able to achieve ad-hoc extensions similar to a MOP. These two classes of mechanisms are actually quite orthogonal, and can be used together. For example, developers can provide frameworks or interpreters in a library, and each interpreter 'instance' can easily export a set of mirror capabilities (which may then be fed to the application as arguments). [1] Mirrors: Design Principles for Meta-level Facilities of Object-Oriented Programming Language. Gilad Bracha and David Ungar. http://bracha.org/mirrors.pdf [2] The Newspeak Programming Platform. http://bracha.org/newspeak.pdf (sections 3,4). [3] Maude Manual Chapter 11: Reflection, Metalevel Computation, and Strategies. http://maude.cs.uiuc.edu/maude2-manual/html/maude-manualch11.html We can use power responsibly. The trick is to control who holds it, so that power is isolated to the 'responsible' regions of code. Regards, Dave ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
