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