Decorator implementation conflicts with Draper

[betamatt]

Both implementations define decorate.

It seems that Contract's decorators are intended only for internal consumption and could be hidden away. One strategy is to have a single "engine" variable which is composed onto a class. The engine contains all data and methods required by Contracts and effectively provides a namespace, preventing any instance variables and methods from conflicting with those defined by the class. All functionality is accessed through the engine instance which contains a reference to the owning class such that object.decorate becomes object.contracts.decorate.

[waterlink]

Yes, you are right. We should somehow hide it. Not sure about engine object approach now, but might use that as well.

[waterlink]

Additionally we have .fetch_decorators, .pop_decorators and common_method_added, these should be probably hidden too.

[waterlink]

And we add .owner_class for eigenclasses (singleton classes)

[waterlink]

@betamatt can you try this branch from my fork: https://github.com/waterlink/contracts.ruby/tree/non_intrusive_method_decorators if it works for you?

It is still pretty dirty hack, so I don't create a PR yet, I will need to clean it up later.

[betamatt]

Examined. The code appears to be the general solution I described. I tested it on my app and it appears to preserve contract behavior while preventing collision with gems such a Draper. 👍

Thanks so much.

[alex-fedorov]

I will clean it up today in the evening and hopefully create a PR