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]
