On Wed, 09 May 2012 13:23:03 +0100, Stewart Gordon <smjg_1...@yahoo.com>
wrote:
On 09/05/2012 11:55, Regan Heath wrote:
Reading that summary, and deadalnix's further comment I am inclined to
agree that
contracts should be (a) static.
It also made me think.. are we defining in/out contracts in the wrong
place? or in the
wrong way? What if we defined them on interfaces instead of classes?
We should be able to define contracts on interface methods, abstract
class methods and normal class methods on an equal footing.
http://d.puremagic.com/issues/show_bug.cgi?id=6549
<snip>
Perhaps we could have both static and dynamic contracts? Contracts
defined on classes (not
interfaces) could remain dynamic as they are currently, but contracts
defined on
interfaces could be static. Giving us the best of both worlds.
I'm not sure what the point of this would be. What is the best of the
dynamic contract world?
I've only read the summary, so... If there is no consensus then someone
obviously sees some benefit to it. Personally, as I said, I think
"static" is the 'correct' way for contracts to work, but perhaps the
reason why ppl like dynamic is that 'correct' is not always 'practical' or
'useful'. Having dynamic contracts allows sub-classes to alter them, that
could be a benefit to some. It doesn't seem 'correct' to me, violating
the substitution principle and all, but I can see how it might be
practical/useful.
Moreover, classes define an API in the same way as interfaces do.
Yes, but an API is only one part or one form of contract. in/out
contracts provide additional limitations/guarantees, beyond what a
"standard"(*) OOP API does. For example, a "standard"(*) OOP API can only
define the type of input, not the range of acceptable values.
(*) I'm saying "standard" here because I'm referring to the common usage
of class, sub-class, interface without the addition of more complex
template, static if, mixin, or other language features not common to the
main OOP languages; C++, Java, C#, ..
Violating a contract on a class method is violating the API in the same
way as it is for interfaces. It would be arbitrary and confusing to
have this conjured-up difference between classes and interfaces.
I agree, classes and interfaces define APIs. But, an interface is
generally thought of as a more formal API, somehow /more/ of a contract
than whatever methods happen to exist in a class at a given time. in/out
are currently used as an additional contracts, and currently applied to
class methods. But, is that 'correct'?
It seemed to me it might be cleaner/clearer and more correct to require
in/out to be applied only to interfaces, where there is no concrete
implementation. Having applied them to classes and moreover to specific
implementations of methods in classes we've created the idea that they
could be dynamic and I suspect the current dynamic implementation in DMD
just followed naturally from that.
I agree, having different behaviour for interfaces/classes /might/ be
confusing.. Then again, I would expect static behaviour from an in/out
defined on an interface, and it seems that some people expect dynamic
behaviour from in/out defined on classes so it's possible that it's just
the behaviour people would expect. In any case I only suggested it as a
possible middle ground.
Personally I'd like to explore the idea that it might be less confusing
and more correct to require the use of an interface to define in/out
contracts. Would that be too much of a burden? Would it result in a huge
number of "redundant" interfaces? Or, would it force people to write more
correct code? I know I've see /a lot/ of code which would have been
written better had someone had the forethought to design the
interfaces/contracts first, and once they exist would have thought harder
about changing them during initial development and beyond.
Regan
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
