[Pkg] SystemEditor: SystemEditor-mtf.117.mcz

[squeak-dev-noreply at lists.squeakfoundation.org]

A new version of SystemEditor was added 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!