Turns out this was not a very good idea
Turns out this was not a very good idea

* In an experimental branch I created Literal objects that respond to
  :call and started to use them within the expressions. The problem was
  that overall there was a very large increase in code, and a slight
  decrease in some localized complexity in Inclusion.

  Using normal ruby objects is good enough for representing Literal
  objects, and there is no (current) need for wrapper objects.

  When the optimization refactoring is done, Inclusion will become
  very small, and most of the optimization logic will be outside
  of the Inclusion object. Maybe wait until this is done to look
  at refactoring Range vs. Enumerable handling.

  Not sure yet how to remove all of the core_ext patches, but some of
  them, like Range#to_inclusive can probably be performed inside the
  Inclusion::Range class.

dkubb/axiom