Marcel Taeumel uploaded a new version of 60Deprecated to project The Trunk:
http://source.squeak.org/trunk/60Deprecated-mt.36.mcz

==================== Summary ====================

Name: 60Deprecated-mt.36
Author: mt
Time: 14 May 2019, 11:15:53.587441 am
UUID: 7b01f304-cfa6-b848-818b-98095b09b7c4
Ancestors: 60Deprecated-pre.35

Deprecates some temporary messages of AbstractEvent.

=============== Diff against 60Deprecated-pre.35 ===============

Item was added:
+ ----- Method: AbstractEvent class>>comment1 (in category '*60Deprecated-temporary') -----
+ comment1
+ 
+ "Smalltalk organization removeElement: #ClassForTestingSystemChanges3
+ Smalltalk garbageCollect 
+ Smalltalk organizati
+ 
+ classify:under:
+ 
+ 
+ SystemChangeNotifier uniqueInstance releaseAll
+ SystemChangeNotifier uniqueInstance noMoreNotificationsFor: aDependent.
+ 
+ 
+ aDependent := SystemChangeNotifierTest new.
+ SystemChangeNotifier uniqueInstance
+ 	notifyOfAllSystemChanges: aDependent
+ 	using: #event:
+ 
+ SystemChangeNotifier uniqueInstance classAdded: #Foo inCategory: #FooCat
+ 
+ 
+ 
+ | eventSource dependentObject |
+ eventSource := EventManager new.
+ dependentObject := Object new.
+ 
+ register - dependentObject becomes dependent:
+ eventSource
+ 	when: #anEvent send: #error to: dependentObject.
+ 
+ unregister dependentObject:
+ eventSource removeDependent: dependentObject.
+ 
+ [eventSource triggerEvent: #anEvent]
+ 	on: Error
+ 	do: [:exc | self halt: 'Should not be!!']."!

Item was added:
+ ----- Method: AbstractEvent class>>comment2 (in category '*60Deprecated-temporary') -----
+ comment2
+ 
+ "HTTPSocket useProxyServerNamed: 'proxy.telenet.be' port: 8080
+ TestRunner open
+ 
+ --------------------
+ We propose two orthogonal groups to categorize each event:
+ (1) the 'change type':
+ 	added, removed, modified, renamed
+ 	+ the composite 'changed' (see below for an explanation)
+ (2) the 'item type':
+ 	class, method, instance variable, pool variable, protocol, category
+ 	+ the composite 'any' (see below for an explanation).
+ The list of supported events is the cross product of these two lists (see below for an explicit enumeration of the events).
+ 
+ Depending on the change type, certain information related to the change is always present (for adding, the new things that was added, for removals, what was removed, for renaming, the old and the new name, etc.).
+ 
+ Depending on the item type, information regarding the item is present (for a method, which class it belongs to). 
+ 
+ Certain events 'overlap', for example, a method rename triggers a class change. To capture this I impose a hierarchy on the 'item types' (just put some numbers to clearly show the idea. They don't need numbers, really. Items at a certain categories are included by items one category number higher):
+ level 1 category
+ level 2 class
+ level 3 instance variable, pool variable, protocol, method.
+ 
+ Changes propagate according to this tree: any 'added', 'removed' or 'renamed' change type in level X triggers a 'changed' change type in level X - 1. A 'modified' change type does not trigger anything special.
+ For example, a method additions triggers a class modification. This does not trigger a category modification.
+ 
+ Note that we added 'composite events': wildcards for the 'change type' ('any' - any system additions) and for the 'item type' ('Changed' - all changes related to classes), and one for 'any change systemwide' (systemChanged).
+ 
+ This result is this list of Events:
+ 
+ classAdded
+ classRemoved
+ classModified
+ classRenamed (?)
+ classChanged (composite)
+ 
+ methodAdded
+ methodRemoved
+ methodModified
+ methodRenamed (?)
+ methodChanged (composite)
+ 
+ instanceVariableAdded
+ instanceVariableRemoved
+ instanceVariableModified 
+ instanceVariableRenamed (?)
+ instanceVariableChanged (composite)
+ 
+ protocolAdded
+ protocolRemoved
+ protocolModified
+ protocolRenamed (?)
+ protocolChanged (composite)
+ 
+ poolVariableAdded
+ poolVariableRemoved
+ poolVariableModified
+ poolVariableRenamed (?)
+ poolChanged (composite)
+ 
+ categoryAdded
+ categoryRemoved
+ categoryModified
+ categeryRenamed (?)
+ categoryChanged (composite)
+ 
+ anyAdded (composite)
+ anyRemoved (composite)
+ anyModified (composite)
+ anyRenamed (composite)
+ 
+ anyChanged (composite)
+ 
+ 
+ 
+ To check: can we pass somehow the 'source' of the change (a browser, a file-in, something else) ? Maybe by checking the context, but should not be too expensive either... I found this useful in some of my tools, but it might be too advanced to have in general. Tools that need this can always write code to check it for them.  But is not always simple...
+ 
+ 
+ Utilities (for the recent methods) and ChangeSet are the two main clients at this moment.
+ 
+ Important: make it very explicit that the event is send synchronously (or asynchronously, would we take that route).
+ 
+ 
+ 					category
+ 						class
+ 							comment
+ 							protocol
+ 								method
+ OR
+ 				category
+ 				Smalltalk
+ 					class
+ 						comment
+ 						protocol
+ 						method
+ ??
+ 
+ 
+ 
+ 						Smalltalk	category
+ 								\	/
+ 								class
+ 							/	  |	\
+ 						comment  |	protocol
+ 								  |	/
+ 								method
+ 
+ "!

Item was added:
+ ----- Method: AbstractEvent class>>comment3 (in category '*60Deprecated-temporary') -----
+ comment3
+ 
+ "Things to consider for trapping:
+ ClassOrganizer>>#changeFromCategorySpecs:
+ 	Problem: I want to trap this to send the appropriate bunch of ReCategorization events, but ClassOrganizer instances do not know where they belong to (what class, or what system); it just uses symbols. So I cannot trigger the change, because not enough information is available. This is a conceptual problem: the organization is stand-alone implementation-wise, while conceptually it belongs to a class. The clean solution could be to reroute this message to a class, but this does not work for all of the senders (that would work from the browserm but not for the file-in).
+ 
+ Browser>>#categorizeAllUncategorizedMethods
+ 	Problem: should be trapped to send a ReCategorization event. However, this is model code that should not be in the Browser. Clean solution is to move it out of there to the model, and then trap it there (or reroute it to one of the trapped places).
+ 
+ Note: Debugger>>#contents:notifying: recompiles methods when needed, so I trapped it to get updates. However, I need to find a way to write a unit test for this. Haven't gotten around yet for doing this though...
+ "!

Item was added:
+ ----- Method: AbstractEvent class>>saveChangeNotificationAsSARFileWithNumber: (in category '*60Deprecated-temporary') -----
+ saveChangeNotificationAsSARFileWithNumber: aNumber 
+ 	"Use the SARBuilder package to output the SystemChangeNotification 
+ 	stuff as a SAR file. Put this statement here so that I don't forget it 
+ 	when moving between images :-)"
+ 	"self saveChangeNotificationAsSARFileWithNumber: 6"
+ 
+ 	| filename changesText readmeText dumper |
+ 	filename := 'SystemchangeNotification'.
+ 	dumper := self class environment at: #SARChangeSetDumper ifAbsent: [ ^self ].
+ 	changesText := 
+ '
+ 0.6 Version for Squeak 3.7 (no longer for 3.6!!!!) Changed one hook method to make this version work in Squeak3.7. Download version 5 from http://www.iam.unibe.ch/~wuyts/SystemchangeNotification5.sar if you are working with Squeak 3.6.
+ 
+ 0.5 Updated the safeguard mechanism so that clients with halts and errors do not stop all notifications. Added and updated new tests for this. If this interests you have a look at the class WeakActionSequenceTrappingErrors.
+ 
+ 0.4 Ported to Squeak 3.6.
+ 
+ 0.3 Added the hooks for instance variables (addition, removal and renaming). Refactored the tests.
+ 
+ 0.2 Added hooks and tests for method removal and method recategorization.
+ 
+ 0.1 First release'.
+ 	readmeText :=
+ 'Implements (part of) the system change notification mechanism. Clients that want to receive notifications about system changes should look at the category #public of the class SystemChangeNotifier, and the unit tests.
+ 
+ VERY IMPORTANT: This version is for Squeak 3.7 only. It will not work in Squeak version 3.6. Download and install the last version that worked in Squeak 3.6 (version 5) from the following URL: http://www.iam.unibe.ch/~wuyts/SystemchangeNotification5.sar'.
+ 
+ 	(dumper
+ 		on: Project current changeSet
+ 		including: (ChangeSet allChangeSetNames
+ 				select: [:ea | 'SystemChangeHooks' match: ea])) changesText: changesText;
+ 		 readmeText: readmeText;
+ 		 fileOutAsZipNamed: filename , aNumber printString , '.sar'!