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:.  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.


> 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.

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.


>
> - Bert -
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091216/c6f3ff19/attachment.htm