aasm/aasm — pull request #137 by ivantsepp (2014-06-05 14:14:27+00:00)
Title: Use `AASM::Methods` as the module to be included

There is an issue with `include AASM` directly in the classes because `AASM` gets added to the ancestor chain and its constant table will be in the path of Ruby's constant lookup algorithm.

Here's an example:
```ruby
require 'aasm'

class Event
def foo
"bar"
end
end

class Job
include AASM

def foo
Event.foo # I expect ::Event but instead get AASM::Event
end
end
job = Job.new
job.foo
# => `foo': undefined method `foo' for AASM::Event:Class (NoMethodError)
```

That means we cannot expect any of the following to resolve correctly:
```ruby
> AASM.constants
=> [:VERSION,
:InvalidTransition,
:UndefinedState,
:Base,
:InstanceBase,
:Transition,
:Event,
:State,
:Localizer,
:StateMachine,
:Persistence,
:ClassMethods]
```

A workaround for this is to explicitly use the scope resolution operator prefix to get to the top level scope (eg . `::Event`) but I think AASM should be structured in a way that doesn't make users do this.

---

What this pull request does is change the API usage from `include AASM` to `include AASM::Methods`. `AASM::Methods` defines the same `included` block as `AASM` so the initialization code is executed properly. `AASM`'s instance level methods are now in `AASM::InstanceMethods`.

Let me know what you think of this change and whether `Methods` is a good naming choice.