On Sun, Mar 11, 2018 at 11:23 AM, Tim Johnson <digit at sonic.net> wrote:

> 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:
>
> <snip>

>
> [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.
>
> Hi.

I don't think that #organizationFiltered: is a method to be sent to
MethodFinder often.  It was probably used to initialize the arrays of
methods to use - and the comments where it was called out look to be notes
to a future instance of the individual that added the notes to come back in
and add those methods.  Which probably didn't happen.

If you notice the comments for the class MethodFinder, it start off near
the top saying:
    "Done by brute force, trying every possible selector."
This means it tries to run each method against the first element of the
candidate you pass into MethodFinder.  if there are bad side effects (such
as #becomeForward:, say) then you really, REALLY don't want to run those
methods against the first object - you could wind up destroying the image
(or, worst case, destroying things on your system!)

Dangerous is to try and protect against those methods - calling out ones we
really don't ever want to run.

On the other hand, if you are adventurous, then you can run the
#organizationFiltered: method against a new class and pull in those methods
to try.  This would then give you a string that you could paste into one of
the #initialize methods (probably #initialize3) following the pattern of
previous authors.  But, make sure to look over those methods and think
about what would happen if passed to an object - such as a
FileDirectory,and remove any additional ones that are dangerous.  And
ideally add those dangerous ones to #noteDangerous.

As to where to put a call to  #noteDangerous, I'd strongly suggest adding
it to #organizationFiltered:, right at the beginning.  It is the only
method that uses it, and there isn't any other reason to build that array.


> Thanks for reading.
>
Thanks for being interested - and pushing down this far.  I'd noticed the
variable before, but hadn't drilled down enough to track down WHY it was
nil.  I enjoyed the push.

>
> Best,
> Tim
>
>
>
-cbc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180316/2d16355f/attachment.html>