problem: Equals interface

[zhiburt]

As you may know there's issue #39
Problem: If you create Equals method and use it anywhere in methods generator replace that expression.

example

func(ss SliceType) NotEqual(rhs SliceType) bool {
   return !ss.Equals(rhs)
}

when you call go generate expression !ss.Equals(rhs) will be replaced on !(ss != rhs)

I consider for solving this one, should check type of element which call Equals but might there be a better solution.

[elliotchance]

One way is to ensure that there is always a fixed variable name on the left, which I originally had, like mightBeString.Equals(foo). It would require an extra variable assignment (not sure if Go will optimize this away), but it would make locating and replacing much easier and more reliable.

[zhiburt]

Hi @elliotchance nice thought have just come to my mind, as I'm thinking, Perhaps the easiest way to solve all these problems is generating equals method by default for each type.
I suppose there's sense in that.
Haw are you feeling about it?

Summarize my proposal,
func (e SliceElement) Equals(rhs SliceElement) bool { return e == rhs } will be generated by generator by default if there is no user's defined one.(for types with pointer will be generated for*SliceElement)

In my opinion your solution will crush out many problems, but probably it doesn't the best way.

[elliotchance]

@zhiburt I have a few objections to this:

1. All of the code generated by pie goes into a different file that can easily be replaced. If we were to create an Equals method it would have to not be put into this file otherwise updating would remove the changes. This is very complicated and in the best case would lead to Equals being put somewhere that's probably wrong.

2. I don't want pie to start imposing code like this. Especially as the interfaces get more complicated that just Equals() and String(). Pie should be able to make do with what it has, but allow more control for those cases where equality needs to be defined.