edisonywh / behaves Goto Github PK

Problem

Currently behaves uses at_exit to run checks for behaves_like. The problem with this is that this screws with rspecs's raise_error.

I've opened up an issue over at rspec/rspec-expectations#1117

I'm trying to look for an alternative if there's one, feel free to make a PR if you know of any.

Rationale

The reason for using at_exit is as follow:

The point of at_exit is so that you can put your behaves_like at the top of the file.

Because code is evaluated from top to bottom, there's no way for behaves_like to know what method the class has implemented, unless you put it all the way down at the bottom, after the declaration of all methods, which is ugly and unconventional.

As of now the current behavior is if class B doesn't implement the #run function, it will fail.

class A
  extends Behave

  implements :run
end

class B
  extends Behave

  behaves_like A
end

What if we have something like this, class B behaves like A but lets say they have a common function with the same implementation logic, in that case class B don't necessarily have to implement the method #run again, so when an instance of class B invokes #run we will now call the function defined in class A.

class A
  extends Behave

  implements :run

  def run
    "run somewhere"
  end
end

class B
  extends Behave

  behaves_like A
end

b = B.new
b.run() -> invokes the function defined in A. # run somewhere

The example class Animal seems useless (for creating objects)

Also would be good to have example for "multi-inheritance"

module Hunter
  extend Behaves

  implements(:hunt)
end

module Prey
  extend Behaves

  implements(:run, :hide)
end

class Shark
  extend Behaves

  behaves_like Hunter
  behaves_like Prey

  # Something something
end

As pointed out by @PikachuEXE over at #12, errors won't actually get raised until exit is called. This is because of the use of at_exit, which only gets run... at exit.

Pikachu has proposed a new syntax, which uses block to mitigate this issue over at #12.

Pros:

• Much easier to reason and understand when is the actual check ran
• Mitigate a couple of other issues like #2 (which was temporarily fixed by testing private method).

Cons:

• Drastically different usage, less "ruby-like", more opinionated (has to define methods inside block)

I'm not sure what's the best way to go about this here so opening this up for discussion, however Pikachu's proposal, despite changes the usage, has the cleanest strategy so far, so I'm leaning towards that.

Steps to reproduce

• After cloning behaves, in the same folder you can do bin/console which brings up a console to play with.

• Paste in this snippet of code:

class Animal
  extend Behaves

  implements :method_one, :method_two
end

class Dog
  extend Behaves

  behaves_like Animal
end

• You'll see that the errors aren't raised until you type exit.

Anyone care to chime in? :)

Currently, the tests are pretty simplistic in that it always çreate the Behavior Object as a class. Logically (untested) it should more or less work the same for Module, but it's good to add specs for some sanity check and to verify that it actually works.

When specs are added and it is verified to work, we could also add this into the README detailing that both Module and Class would work.

See #13

class Animal
  extend Behaves

  implements :method_one
end

class Dog
  extend Behaves

  behaves_like Animal

  def method_1
    "hello"
  end
end

When we do this:

dog = Dog.new
dog.behaves_like # returns Animal

I may have a collection of objects, and i will like to do some operations on them. Hence i can decide if these object behaves_like a certain type, i want perform an operation which is related to this class, since it will definitely define the method its required to implement and the injected behavior.

I ended up adding this as an initializer

Object.send :extend, Behaves

to avoid typing extend Behave all the time.