Inherited contracts

[nixpulvis]

This is a pretty common use case (for me at least). I define a base class:

class Base
  # ...
  Contract String => String
  def foo(arg)
    # ...
  end
  # ...
end

Next I write a bunch of subclasses from Base. I might write a bunch of new methods on these subclasses, but sometimes I also need to overwrite the definition of a function.

class A < Base
  # ...
  def foo(arg)
    # New stuff.
  end
  # ...
end

By default it would be ideal for the contract of Base#foo to be given to A#foo, allowing a new contract to overwrite the inherited one if needed.

[egonSchiele]

Hmm, I don't agree with this. One reason I like contracts, the contract is right above the method definition. So I don't have to go hunting to understand what a method is doing. If you see a method with no contract on it, and then it throws a contract error, that could get confusing.

I can see this being an issue when you are overriding a bunch of one line methods. But I would rather have that be more verbose for the sake of clarity.

[nixpulvis]

Maintaining interfaces is the most important thing this library provides. If I need to duplicate an contract then I need to maintain n contracts for the same interface, where n is the number of implementors of the interface.

The blaming feature should be able to handle pointing contract failure to the correct location.

[stevesun21]

I have the question, why the contracts I wrote on the "interface" cannot be inherited?

So far, I have to use proxy pattern to solve this problem.

class Base
  # ...
  Contract String => String
  def foo(arg)
    # ...
  end

  def proxy(client)
    @client = client
    self
  end
  # ...
end

usage:

obj = Base.new.proxy(A.new).foo(...)

[waterlink]

There is one solution: stop using inheritance for code reuse - it only increases coupling and calls more problems. Use composition instead.

[waterlink]

There was no so much activity here, and I am reluctant to closing this because @egonSchiele thinks that it is important to spell out contracts explicitly for each method.

WDYT?

[nixpulvis]

While I agree with you in general there are two reasons I see this as important nonetheless.

1. People do not all agree that they should not use inheritance, and given that Ruby explicitly supports it people will use it.
2. Enforcing contracts on subclasses actually makes inheritance a better option in some cases. It adds structure to interfaces developed for reuse.

[sebnozzi]

Maybe method-overrides could be intercepted and an exception be thrown if the new version lacks a conforming contract annotation? For inspiration, do take a look at how the Eiffel language deals with contracts and inheritance.

[nixpulvis]

That seems like more work than just assuming that all methods denied from #foo adhere to it's contract unless explicitly stated.

[sebnozzi]

@nixpulvis You can assume that, but you won't see it by looking at the code (without knowing the superclass). But then again, I'm mainly a Scala developer, where you have to explicitly state that a method is being overridden in a subclass (which I dearly miss in Ruby - but where I can understand why this is not "supported"). So I am biased towards more boilerplate and explicitly stating things...

[waterlink]

Actually I like @sebnozzi 's idea about validating inherited methods contracts. WDYT @egonSchiele ?