On Wed, Sep 7, 2011 at 12:48 PM, Casey Ransberger <[email protected]>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 [email protected] http://vpri.org/mailman/listinfo/fonc
