>From VM's perspective , all object are just a state holders, with slots and
determined size(s).
In language environment, however, the objects are treated as a
black-boxes to which you can
send the messages only.
The debugger is staying somewhere in the middle, i.e. it should know
how to connect these two realms
in order to simulate VM-specific behavior when you stepping over the code.
So, for the means of debugging i tend to agree that mirror prims will
be quite useful.
But same as Bert i don't want to see these prims abused by people who
bypassing the 'black-box' paradigm
by using them, so we ending up with a 'static-type-oriented' C-like
programming instead of object oriented one.

2009/9/7 Eliot Miranda <eliot.miranda at gmail.com>:
> 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 -
>>
>>
>>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.