On 02/29/2012 05:26 PM, Stewart Gordon wrote:
On 29/02/2012 14:44, Timon Gehr wrote:
<snip>
The spec isn't explicit on whether the overridden method retains the
base's in contract unchanged or loses its in contract altogether.
The front page of the web site is quite explicit about this:
What web site? Certainly not www.digitalmars.com or
d-programming-language.org or dlang.org as I look at the moment.
The official website, d-programming-language.org or dlang.org. You have
to click on "See example". It is at the first bulb of "Power".
<snip>
Anyway, probably it is not stated explicitly in the relevant parts of
the spec because it
is assumed that the reader is familiar with similar features in other
languages.
Then it's a hole in the spec. If it's only meant to state how D differs
from some other language, it would have to state what language that is.
It surely is a hole in the spec.
<snip>
Another scenario I've thought of is:
- library class defines a method with an in contract
- application class overrides this method, and has the same argument
restrictions as the library class
- a later version of the library class widens the range of acceptable
inputs
- however, the app's override is not prepared to deal with inputs that
are newly allowed by the API
...
This is not a contract-related problem. It is a breaking API change,
whether or not the
library class defines language level contracts.
How do you mean?
Language level contracts as in D are (basically) a way to introduce
runtime checks into interfaces. If the interface is redefined then that
potentially breaks all code that implements the interface, even if this
is not explicitly stated in form of contracts.
<snip>
Library writers shouldn't silently change functionality and/or
redefine interfaces.
<snip>
So you think that, once a library is written and released, no new
functionality should ever be added?
Obviously there can be additional changes without redefining what an
existing part of the API does.
Timon Gehr wrote:
The new stuff should be introduced under a different name and the old name
should be deprecated.
