Recognize methods defined with class << self syntax as singleton methods.

[troessner]

Fixes #112
The way this works is that we're passing the parent scope for each sexp to Treedresser and then store this parent scope with each adorned ASTNode.
We then check in the UtilityFunction Detector if the parent scope is of type ":sclass".
I believe this is a simple yet elegant solution.

[mvz]

I'm of two minds about this solution. On the one hand it is rather elegant in its simplicity, on the other hand it makes the AST data structure more complex, storing the parent in a lot of places where it won't be needed.

Have you considered putting this logic in the CodeContext classes? They already record their parent context. Perhaps adding a SclassContext would work?

[troessner]

Have you considered putting this logic in the CodeContext classes? They already record their parent context.

Yes, I did consider this.
Let me explain why I think that the above way is a better way than using a CodeContext:

1.) Regarding passing in the parent context: We are traversing the AST with TreeDresser and with TreeWalker. It feels kind of weird and inconsistent that TreeWalker basically allows traversing the tree in both directions, while TreeDresser doesn't.

storing the parent in a lot of places where it won't be needed.

But TreeWalker is the biggest offender in regards to that. If you look at that with a debugger: just a "p self" in a TreeWalker blows up your screen.
I know that the "But this thing is worse" is not the best logic, I'm just mentioning it to keep things in perspective.
And adding just the parent scope is a rather small, sensible addition in my mind that makes sense for TreeDresser.

2.) Regarding the "singleton_method?" in SexpExtensions:
If you look at the current way SexpExtensions work or rather, what kind of functionality is encapsulated there, putting the "singleton_method?" there fits right into purpose of it.
We're adorning the tree with the information that a given method is a singleton_method - this feels just right to me.:)

3.) TreeWalker is a very messy already and it has unclear responsibilities (tree walking, reference counting, smell checking). CodeContexts are a little better but adding anything there would still add technical debt. IMHO this whole TreeWalker should be refactored before we add anything to it at all.

Taking all of the above into account, I believe the solution in this pull request is the cleanest way.

[troessner]

Pinging @mvz - I believe I presented a couple of good arguments for this solution, so if you don't have any serious showstoppers I'd appreciate a merge so we can cross this ages-old bug off of our list.;)

[mvz]

I think this is a good solution for now and we can always revisit it once we start cleaning out TreeWalker.