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
