On Mon, Sep 7, 2009 at 12:34 PM, Bert Freudenberg<bert at freudenbergs.de> wrote:
>
> On 07.09.2009, at 21:29, Eliot Miranda wrote:
>
>> On Mon, Sep 7, 2009 at 12:19 PM, Bert Freudenberg<bert at freudenbergs.de>
>> wrote:
>>>
>>> On 07.09.2009, at 20:56, Eliot Miranda wrote:
>>>>
>>>> I have fixes for this integrated in Qwaq.  This is work I did for
>>>> VisualWorks a while back.  The idea is to add a set of mirror
>>>> primitives, so called because they do reflection, to ContextPart.
>>>> These primitives implement the basic operations of the object model
>>>> needed for execution simulation, fetching an object's class, accessing
>>>> its named and indexed instance variables, and the number of indexed
>>>> instance variables, sending a message, but they take the object
>>>> operated on as a parameter and so do function without sending messages
>>>> to that object.
>>>
>>> Wouldn't that break encapsulation in a way we never had to before?
>>
>> If one dared use those primitives for anything other than simulating
>> the VM then I suppose they're a little worse than instVarAt:put: and
>> basicAt:put:, but not so much.
>
> These are fundamentally different. #instVarAt:put: and basicAt:put: are
> regular methods that an object itself implements to give others access to
> its internal state. It can very well chose not to.

Yes, but they are implemented in Object and potentially defeat
encapsulation on every object in the system that inherits from it
(which is almost all).  In practice this isn't an issue because they
are not abused.  Its the same with the mirror primitives.  So while it
appears the sky can fall in a new way it doesn't.

>
>>  I think it is much more dangerous to
>> have a debugger that appears to be correct but breaks one's code in
>> ways that are horribly difficult to understand.
>>
>> Note that both Self and Newspeak (and VisualWorks) take the mirror
>> primitive approach.  But there is certainly a security issue and one
>> wants to medate access to the mirror primitives carefully.
>
>
> Alas we have no way for restricting access in Squeak.

I can imagine a way using withArgs:evaluate:.  Compile the methods,
save them in class variables of ContextPart and access them through a
checking interface that only allows their execution in the context of
the debugger.  But I still think this is overkill.  What, in Squeak,
is to stop one compiling a method on ProtoObject and using it to
subvert encapsulation on all objects?  Nothing.  So the issue of
security is not made any worse by the introduction of the mirror
primitives, but the debugger is enhanced significantly.  So for me
they're a clear win.


>
> Anyway, these primitives are useful for debugging indeed. How about
> disabling them in production mode?

Alas the process termination code uses execution simulation to
terminate suspended processes and that means using the mirror
primitives to safely terminate processes.  The current non-mirror
implementation could conceivably screw up terminating processes
executing code on encapsulators.

I think a better way is to propose a security mechanism that prevents
their abuse.  Any ideas?

>
> - Bert -
>
>
>