Hi Esteban and Martin,
sorry for my contribution to this topic being so late. I fully agree to
Martin's suggestion of checking if an inspected object conforms to the
rich inspector api before applying it.
For dealing with Glorp, I found an easy solution which Pavel will
integrate soon in the Glorp port he published some time ago. My approach
to find the trigger(s) resolving the proxy was simply hooking
#doesNotUnderstand: with a Transcript trace of the current message. So I
found out that it were only 3, which I list below along with my
implementation in Proxy that stopped any resolving:
gtDisplayString
self isInstantiated
ifTrue: [ ^self class name , ' on ', value gtDisplayString].
^self class name, ' uninstantiated on ', self query resultClass name
gtInspectorVariableNodesIn: aCollection
"Taken from Object, avoiding loop over indexed variables calling
#basicSize"
aCollection
addAll: ((self class allSlots collect: [ :slot |
GTInspectorSlotNode hostObject: self slot: slot ]))
readSlot: aSlot
"Taken from Object, sent by GTInspectorSlotNode"
^aSlot read: self
With this approach, I was not able to trigger proxy resolution by just
navigating in the inspector, I had to explicitely send #getValue to the
slot. Hope this helps until we have a more general solution!
Best regards,
Richard
Am 08.08.2020 um 18:00 schrieb pharo-dev-requ...@lists.pharo.org:
Message: 1
Date: Fri, 7 Aug 2020 20:33:50 -0300
From: Esteban Maringolo<emaring...@gmail.com>
To: Pharo Developers<pharo-dev@lists.pharo.org>
Subject: [Pharo-dev] Tools with Proxy support
Message-ID:
<CAJMgPC+5v4eG+qK3m7LjWmYs3H1J=mwopg_acuu9vccsy5y...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
I'm having a hard time trying to debug some Glorp code in Pharo 8
because the inspectors and the glamour things are triggering the
instantiation of my Proxy objects.
I don't know how the inspectors, variable lists, and other tool work,
but I assume there should be a way to reimplement something in Proxy
to avoid causing a MessageNotUnderstood that triggers the
instantiation.
If there is no way for it (I guess there is, looking at some gt*
selectors in ProtoObject), please consider having a debugPrintString
(and debugPrintOn:) in the upcoming Spec2 based tools.:-)
Best regards,
Esteban A. Maringolo
------------------------------
Message: 2
Date: Fri, 7 Aug 2020 16:59:10 -0700
From: Martin McClure<mar...@hand2mouse.com>
To: Pharo Development List<pharo-dev@lists.pharo.org>, Esteban
Maringolo<emaring...@gmail.com>
Subject: Re: [Pharo-dev] Tools with Proxy support
Message-ID:<49dde322-a79d-1b16-798e-9679ce08b...@hand2mouse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Esteban,
I also have trouble with this sort of thing in Pharo -- inspectors
sending messages to objects under inspection that are not understood, or
that do not respond in the way the inspector expects.
It is possible to build a basic inspector that sends no messages at all
to the inspected object (using the mirror methods), and it would be nice
to have that option in Pharo.
It's also possible to have a "careful" inspector that uses a mirror
method to determine the class of the inspected object, then uses either
the purely-mirroring inspector or the richer inspector, depending on
whether the object's class inherits from Object. Since the GemStone
clients make use of proxy objects, GemStone's inspectors take this
general approach. They're not perfect either, but problems are
considerably fewer.
Regards,
-Martin
