Matthew Fulmer uploaded a new version of SystemEditor to project SystemEditor: http://www.squeaksource.com/SystemEditor/SystemEditor-mtf.117.mcz
==================== Summary ====================
Name: SystemEditor-mtf.117 Author: mtf Time: 18 September 2008, 11:06:01 am UUID: 4a548d30-0c97-4225-b51d-bd1ec559e348 Ancestors: SystemEditor-mtf.116
MethodDictionaryEditor had Dictionary as its superclass, rather than DictionaryEditor; fixed.
Made MetaclassEditor>>isDebuggingAsEditor runtime, rather than compile-time, configurable (just send debug: true to the SystemEditor)
=============== Diff against SystemEditor-mtf.116 ===============
Item was changed: + DictionaryEditor subclass: #MethodDictionaryEditor - Dictionary subclass: #MethodDictionaryEditor instanceVariableNames: 'classEditor' classVariableNames: '' poolDictionaries: '' category: 'SystemEditor-Editors'!
Item was added: + ----- Method: SystemEditor>>debug: (in category 'debugging') ----- + debug: aBoolean + "see MetaclassEditor>>isDebuggingAsEditor" + + debug := aBoolean!
Item was changed: ----- Method: OldMetaclassEditor>>isDebuggingAsEditor (in category 'debugging') ----- isDebuggingAsEditor "To be transparent enough to fool most existing software, MetaclassEditors must answer their subject's instance variables when sent the message allInstVarNames. However, this message is also used by the debugger, inspector, and explorer, when inspecting ClassEditors, and an inspector should see the real instance variables of ClassEditor rather than those of the MetaclassEditor's subject. So there is a conflict of interest already. But it gets worse. If you do open an inspector on an object that is reporting wrong information about it's instance variables, Bad things happen. Specifically, the inspector calls instVarAt: on an instance variable that does not exist, leading to an error every time the display is updated. Less severe, instVarAt: will answer nonsensical. So I took the instance variable proxying behavior all the way so that it successfully fools the debugger, inspector, and explorer into seeing proxied instance variables (see the senders af this message if you want to know how). But there is still the original problem that you, the programmer want to see the real state of ClassEditor. That is where this method comes in. If this method returns false, everybody sees the proxied instance variables. This is the correct behavior. If this method returns false, everyone sees the true instance variables of ClassEditor. This is incorrect behavior, and breaks the Unit tests, but it is invaluable if + you are debugging ClassEditor" + + ^ self environment debug! - you are debugging ClassEditor. - - Just be sure to make sure this returns false whenever making a release" - ^ false!
Item was changed: DictionaryEditor subclass: #SystemEditor + instanceVariableNames: 'organization showProgress debug' - instanceVariableNames: 'organization showProgress' classVariableNames: '' poolDictionaries: '' category: 'SystemEditor-Editors'!
Item was added: + ----- Method: SystemEditor>>debug (in category 'accessing') ----- + debug + "see MetaclassEditor>>isDebuggingAsEditor" + + ^ debug ifNil: [false]!
Item was changed: ----- Method: MetaclassEditor>>isDebuggingAsEditor (in category 'debugging') ----- isDebuggingAsEditor "To be transparent enough to fool most existing software, MetaclassEditors must answer their subject's instance variables when sent the message allInstVarNames. However, this message is also used by the debugger, inspector, and explorer, when inspecting ClassEditors, and an inspector should see the real instance variables of ClassEditor rather than those of the MetaclassEditor's subject. So there is a conflict of interest already. But it gets worse. If you do open an inspector on an object that is reporting wrong information about it's instance variables, Bad things happen. Specifically, the inspector calls instVarAt: on an instance variable that does not exist, leading to an error every time the display is updated. Less severe, instVarAt: will answer nonsensical. So I took the instance variable proxying behavior all the way so that it successfully fools the debugger, inspector, and explorer into seeing proxied instance variables (see the senders af this message if you want to know how). But there is still the original problem that you, the programmer want to see the real state of ClassEditor. That is where this method comes in. If this method returns false, everybody sees the proxied instance variables. This is the correct behavior. If this method returns false, everyone sees the true instance variables of ClassEditor. This is incorrect behavior, and breaks the Unit tests, but it is invaluable if + you are debugging ClassEditor" + + ^ self environment debug! - you are debugging ClassEditor. - - Just be sure to make sure this returns false whenever making a release" - ^ false!
packages@lists.squeakfoundation.org