Michael G Schwern: > Garrett Goebel wrote: > > A derived interface can loosen input constraints... so > > it must be able to either satisfy all inherited pre- > > conditions _or_ its own pre-conditions. > > Looking around, this seems to be regarded as something of a > compromise because truly determining what a real logical > weaking is is hard. Are there other ways to do it, just to > mull them over?
I thought about this for a while while reading your post. There are certainly pre-conditions which you will want to be enforced all the way down the line. And running counter to this is the need to be able to weaken pre-condition constraints to handle a wider range of inputs. Which requires that the derived class not need to satisfy all inherited pre-conditions. So the following wouldn't necessarily DWIM (if you know what I mean): Class Foo { method count($from, $to) { PRE { $to < 10 } PRE { $from >= .lower_bound } } } Class Bar is Foo { method count { PRE { .to < 100 } } } Class Baz is Bar { method count { ... implementation ... } } if you call Bar->count(-1, 99) you're no longer effectively constraining $from >= .lower_bound. if you call Baz->count(-1, 99) you'll fail the Foo precondition. But since you haven't defined any pre-conditions for Baz does this mean you have to satisfy all inherited preconditions or that there are none? I.e. where's the boolean OR logic when inherited pre-conditions are defined, but the derived class' pre-conditions are undefined? So currently, you'll need to rewrite all applicable pre-conditions for each derived class, because you don't know if one of the existing or future refactorings of a super-classes will weaken the input constraints. So you can't assume you'll ever successfully pass all inherited pre-conditions. I.e. you can only trust the class' own pre-conditions. This is where I get pretty fuzzy. How to address the issue? -Assuming I've understood it correctly and that it really is an issue. Can anyone back me up with a yea or neh as to whether or not this is real problem... or just my misunderstanding? I wonder if it might be useful to somehow tag a pre-condition to be invariably enforced ('AND') like post and invariant conditions... or alternatively marked as overridable ('OR' --the default) to allow loosing input constraints. Perhaps replacing the Class Foo example above with: Class Foo { method count($from, $to) { PRE { $to < 10 } # 'is OR' is default PRE is AND { $from >= .lower_bound } } } Class Bar is Foo { method count { PRE { .to < 100 } } } Class Baz is Bar { method count { ... implementation ... } } With two more semantic changes: o modifying the 'OR'ing of a class' inherited pre-conditions to be only one inheritence level deep o a class which has no pre-conditions would be required to satisfy the inherited pre-conditions (no OR if undef) So calling Bar->count(-1, 99) where the current class (Bar) has no pre-conditions would DWIM. I.e., it would have to satisfy the 'OR' pre-conditions from Bar and the 'AND' pre-condition from Foo. Have I walked off into la-la land on a foundation of misunderstandings? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]