Hi all,

I seem to have stumbled into a few issues, and am taking the bold step 
of including them all in a single email.  My apologies.  Tested/explored 
in 6.0a-#17799.

Issues:

[1] The deprecation of SequenceableCollection>>#upTo:

[2] Removing deprecated #defaultBackgroundColor from MethodFinder

[3] MethodFinder class variable Dangerous and 
MethodFinder>>#organizationFiltered:

So:

[1]

The deprecation of SequenceableCollection>>#upTo: means Method Finder 
(a.k.a. Selector Browser) now pops up two modal dialogs if one enters 
something like:

'deprecated '. 'method'. 'deprecated method'

...into its code entry pane and hits 'save'.

This appears to be due to the inclusion of #upTo: in 
MethodFinder>>#initialize2 as a method which would be sent to a 
PositionableStream... which seems reasonable.

According to ReadStream>>#readStream, a ReadStream is intended to be 
polymorphic with SequencableCollection.  So, then, if #upTo: is an 
intrinsic method of a Stream, does this mean it must be retained in 
SequencableCollection? E.g. should it become undeprecated?

Though never until now have I thought about what it would take to use 
Method Finder on a stream!  So I tried something similar to (but not 
exactly) the following in a Workspace:

MethodFinder methodFor: { { 'deprecated' readStream . $c }.  'depre' }  
"changed to protect the innocent user who put array braces in the wrong 
place on his first attempt"

[2]

...and /another/ deprecation warning popped up:

"Object>>#defaultBackgroundColor has been deprecated. Implement 
#uniformWindowColor and #customWindowColor in your model."

...#defaultBackgroundColor appears in method source 23 times, so there 
are probably still a number of places where this deprecated method needs 
to be engineered around :)   However, the place where it's probably 
causing trouble in this case is in MethodFinder>>#initialize.  Attached 
is a change set to remove it from that method.

[3]

However, there is another problem with MethodFinder>>#initialize and 
#initialize2.  They both include comments at their respective ends which 
call MethodFinder>>#organizationFiltered:, but that method fails due to 
the class variable Dangerous being uninitialized.  The method which 
initializes Dangerous, MethodFinder>>#noteDangerous, looks to be unsent. 
  If I add "self noteDangerous" to one of the #initialize methods (I 
added it to #initialize3 to test), this makes #organizationFiltered: 
work again (after initializing MethodFinder).  Note that Dangerous is 
not mentioned in the MethodFinder class comment, but other class 
variables are.  I didn't do any research for how Dangerous is intended 
to be useful.

Thanks for reading.

Best,
Tim
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MethodFinder-Deprecated.cs
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180311/ebee0ee6/attachment.ksh>