Yep. Got it. See my other mail about integrating the reflection methods in Context. This would be enough to get the GTInspector working properly (we already did it but we cannot commit because of missing Context methods). Cheers, Doru
On Nov 19, 2015, at 5:53 PM, Clément Bera <bera.clement@gmail.com> wrote:
2015-11-19 15:31 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
Please tell me more specifically what needs to be done. Could you give me a concrete example of an object that cannot be inspected?
Try this code:
GTInspector inspect: ProtoObject new
Then you can try with instance of subclasses of ProtoObjects with different properties. For example:
ProtoObject variableSubclass: #ProtoArray instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Objects'
GTInspector inspect: (ProtoArray new: 3)
Lastly you can try the hard cases. For example run:
ProtoArray superclass: nil. GTInspector inspect: (ProtoArray new: 3)
The generic problem is that these objects cannot be expected to answer any message, as it can crash the VM, so inspection should happen without the object inspected receiving any message.
Cheers, Tudor
On Nov 18, 2015, at 6:08 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2015-11-18 13:29 GMT-03:00 Clément Bera <bera.clement@gmail.com>:
2015-11-18 8:43 GMT-03:00 Guillermo Polito <guillermopolito@gmail.com>:
Iâd like to discuss also the possibility to add those low level operations on mirrors objects, that could be packaged separately from the kernel of the language. Adding them on a first step is easy, then making all tools use them is the hard/timeconsuming part, yes.
All the needed operations already exist. You can put them on your mirror objects without any problem.
Who takes the decision to put it either in EyeInspector or GtInspector?
Regards!
-- www.tudorgirba.com
"Be rather willing to give than demanding to get."
-- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."