On Tuesday, October 1, 2002, at 12:33 PM, Michael G Schwern wrote:
> Perhaps a way to sharpen the focus on this is to expand the discusson
> of
> strictness to include not just method prototypes but Design-By-Contract
> features as well (pre and post conditions and invariants). Should DBC
> conditions be overridable? Since it's not terribly useful to override
> a
> signature only to be stopped by a pre-condition.
>
> Taken as a whole, I'm leaning towards no. Interfaces and conditions
> should
> be strict. They can be gotten around using delegation, which should be
> built into Perl 6 anyway.
I'd think no, too... if someone doesn't want or need interfaces, they
can just not use them. Which implies, I assume, that "interface" is
not the default state of a class method, e.g. we do need something like
"method foo() is interface { ... }" to declare any given method
specifically as an interface method, if noone has a problem with that.
Just to be clear, I'm not thinking we can get away with saying "all
nonprivate methods are automatically interfaces", for example.
>> My musing is that the behavior of a class in different contexts is
>> itself an interface, in the sense of being a contract between a
>> class/subclass and it's users
>
> Ah HA! Contract! Return values can be enforce via a simple DBC post
> condition, no need to invent a whole new return value signature.
I think I get it, but can you give some pseudocode? If you want a
method to return a list of Zoo animals in "list" context, and a Zoo
object in "Zoo object" context, what would that look like?
(I'm assuming that DBC postconditions on a method would be treated,
internally, as part of the overall signature/prototype of the method:
i.e. if you override the method in a subclass, all original
postconditions would still remain attached to it (though the new method
might itself add additional postconditions.))
MikeL
