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
