[squeak-dev] Mirror prims
bert at freudenbergs.de
Wed Dec 16 19:24:35 UTC 2009
On 16.12.2009, at 18:43, Eliot Miranda wrote:
> On Wed, Dec 16, 2009 at 2:21 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 16.12.2009, at 03:11, David T. Lewis wrote:
> > On Tue, Dec 15, 2009 at 08:35:55PM +0100, Levente Uzonyi wrote:
> >> We should definitely keep the tests. After a bit of googling I found
> >> Eliot's email which didn't get much attention:
> >> http://lists.squeakfoundation.org/pipermail/vm-dev/2009-September/003161.html
> >> This explains everything about mirror primitives. I wonder why these
> >> changes aren't integrated into VMMaker. (Note that ContextPart >>
> >> #objectClass: is missing from the attached source, I added an
> >> implementation to the trunk). I marked the failing tests as expected
> >> failures.
> > Thanks for the pointer. I somehow completely overlooked this posting
> > on the vm-dev list. I opened a Mantis issue for "Add Mirror Primitives
> > to the VM" to track it.
> > http://bugs.squeak.org/view.php?id=7429
> > Dave
> IIUC these new primitives break object encapsulation, which is fundamental change to the VM.
> Do we care?
> Very much so. The implementation of the execution simulation machinery (the debugger) is incorrect without them. For example, if you step through code on an encapsulator using the existing machinery every time an attempt is made to access an instance variable the message instVarAt: will get sent to the encapsulator, which will catch it in its doesNotUnderstand: method and answer an entirely erroneous value.
> The execution simulation machinery *must not* send messages to access state for correctness. The VM does not send messages to access state; the execution simulation machinery must mimic the VM.
> This is not much worse a violation of encapsulation than instVarAt: and instVarAt:put:.
It is fundamentally different, because those methods actually have to be implemented in the object. My object can intercept #instVarAt: but not the mirror prims.
> Yes, the facilities can be misused, but so can thisContext, instVarAt: and much other reflective machinery. In practice they are not misused and their power by far repays their danger.
> On the other hand, not being able to debug exotic code is a serious problem. This is often the kind of code one most needs help with.
Agreed, the facility is useful in debugging exotic code. Most code isn't exotic though. So my question stands if we want to compromise the whole system for these exotic situations. Since the facility is useful it might be okay to include if we can turn it off.
> If so, do we still want them?
> If yes, should there be a way to disable them, similarly to how we can disable file access?
> In the short/medium term, unload the debugger, the compiler, and any other reflective machinery.
Won't help, since with access to that primitive my object can do pretty much anything.
> In the bright rosy future concoct a convincing story around capabilities or mirrors which carefully modulate use of these facilities so they can't be misused.
That's exactly my point - I don't see how you could do a safe capability-based system with those primitives that can work around any encapsulation and hence can circumvent any capabilities.
- Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev