On Thu, Oct 03, 2002 at 04:47:26PM -0500, Garrett Goebel wrote:
> > And if we make pre/post conditions and class invariants
> > always enforced...
>
> no.
>
> post-conditions and invariants are always enforced, but pre-conditions are
> different.
Right, right.
> 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?
> > ....shouldn't we have private invariants and conditions?
>
> no.
Ummm, why?
> I should inject that I disagree with the use of term private as meaning
> non-inheritable. I think of private as an methods and attributes accessible
> only within the namespace of that class or its descendants.
Isn't that "protected"?
As I understand it, Perl 6's private will be non-inheritable methods
accessable only inside the class which defined it. Ruby does it this way,
AFAIK.
> Perhaps a better
> term would be something like:
>
> method foo is disinherited { ... }
is disowned
is get_a_haircut_and_a_job
is i_have_no_son
;)
> I also need to separate out the DBC topic from the interface one. For
> instance I have a hard time thinking about attributes in the context of
> interfaces. For me, interfaces should be limited to a bunch of abstract
> methods with conditions. Any other declarations within an interface IMO
> should be errors. I.e., all other declarations belong in the implementation
> class...
I hope we're not going to explicitly seperate interfaces from
implementation. ie. That you can define an interface at the same time as
you implement it. This is something I really like about Perl as opposed
to other OO systems, class definition and implementation are not kept
seperate.
class Human is interface {
attr head, shoulders, knees, toes;
invar { .head == 1 }
invar { .shoulders == 2 }
invar { .knees == 2 }
invar { .toes == 10 }
method talk ($say,$how_loud) {
$say.uc if $how_loud >= 10:
print "$say\n";
}
}
Of course, if "interfaces" in the Java sense are just classes with no
implementation details, there's no reason why you can't do it seperately.
class AbstractHuman is interface {
attr head, shoulders, knees, toes;
invar { .head == 1 }
invar { .shoulders == 2 }
invar { .knees == 2 }
invar { .toes == 10 }
method talk ($say,$how_loud);
}
class Human isa AbstractHuman {
method talk ($say,$how_loud) {
$say.uc if $how_loud >= 10:
print "$say\n";
}
}
The above would result in the same thing. The latter explicitly seperates
the interface from the implementation, as some like, while the former does
them all in one class, as others like.
> If you want to have a public and private "inheritable" interfaces that's
> fine. But what's the point of a non-inheritable interface? Myself, I call
> non-inheritable methods "functions".
"Interface" is not quite simply the union of "method signature",
"conditions" and "invariants". Interfaces are a combination of the three,
true, but it's only a subset of their use. They're all useful beyond simply
enforcing how subclasses are designed and implemented.
Method signatures are obviously used to define how methods are to be called
by outside users of the object, as well as change the contexts in which the
arguments are parsed.
Pre/post conditions and invariants, when private (ie. not inherited) can be
used like assertions, guaranteeing that internal state and implementation
details are kept sane. My ATV example may not have been clear enough in
that I considered the tilt check to be an internal state check and not a
documented feature of the object. A clearer example might be something like
checking that an internal data structure used by the object is not circular.
A class invariant, yet not something I want to enforce on my children.
They're tools that when combined form an "interface" but are still useful
seperately.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
The key, my friend, is hash browns.
http://www.goats.com/archive/980402.html
