On Fri, Oct 04, 2002 at 02:44:24PM -0500, Garrett Goebel wrote:
> > > > ....shouldn't we have private invariants and conditions?
> > >
> > > no.
> >
> > Ummm, why?
>
> Maybe I'm just grinding an ax...
>
> If you allow an interface's post conditions and invariants to be overlooked,
> then you've got a broken interface.
***************************
But they're *not part of the interface*
***************************
Just to make it clear. :) Conditions and invariants are part of but
not exclusive to the interface of a class. They're just well-done
assertions. When inherited, they're part of the interface. When
private and used as assertions on implementation detail, they're just
assertions.
The ability to define conditions on a class which must remain true at
all times (mod the details of DBC rules) is very powerful and
shouldn't be limited to simply defining an interface. Pre/post
conditions about implementation details may not be terribly useful,
but class invariants will.
> I think my ax could rest more peacefully if I could see more clearly how the
> syntax would allow us to clearly disambiguate between the interface and the
> implementation; constraints on a method's inputs and outputs as separate
> from how its implemented.
This is what I'm proposing.
invar { .foo eq 'bar' } # interface
invar { .wibble eq 'miff' } is private # implementation
It's inherited by default, and not inherited if declared private.
Same as a method.
> > 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.
>
> I hope we do when we explicitly flag a class as an interface. After all, a
> class which isn't explicitly qualified as an interface still has one.
I think the trouble here is that not everyone is going to want method
signatures strictly enforced on their subclasses. So what the default
behavior will be is really a matter of the philosophy of our OO
implementation. Right now I'm assuming signatures will not be
enforced unless you specify the class with an 'interface' property,
but I could go either way.
Conditions and invariants, OTOH, will always be enforced (unless
declared private) otherwise they have little purpose.
> But I suppose that is what your private idea is all about. In the
> context of a class private means "just don't inherit this". In the
> context of an interface private means "this is not part of the
> interface". It still looks like it'll be messy when deep inheritence
> is involved.
Private, how I see it, means "don't inherit this *and* it can't be
used outside the scope of this class". That second bit implies it's
not part of the interface.
To clarify:
class Foo {
method _bar is private {
...
}
method something {
._bar("foo"); # ok, we're inside Foo
}
}
my $foo = Foo.new;
$foo._bar; # not ok. Even though we've got a Foo object,
# we're outside the class declaration and can't
# call private methods.
> However, I would still disagree with allowing private conditions on
> non-private methods. At least not when you're tagging the class with a label
> declaring it to be an interface, since non-private methods are implicitly
> part of the interface.
But the private conditions are not part of the interface, even when
placed on a public method. It's just a fancy assertion. It might
help if you mentally s/private (condition|invariant)/assertion/g to
help think of how they can be used seperate from in an interface.
Just to clarify, in my world implementation and interface do not have
to be seperated. An "interface" is merely a class which enforces it's
method signatures on it's subclasses.
> In short, go ahead and write it in a single class. You know where the
> interface leaves off and the implementation begins. Just don't hang the
> 'Interface' attribute off it.
I think most of what we're arguing about is what baggage term
"interface" carries with it. I'm neither from a DBC nor Java
background, so to me "interface" just means "how you use the thing"
and it happens to be inherited. I think you're reading more into it
than my deliberately simplistic definition.
The other part that's up in the air is if method signatures will be
enforced on subclasses by default or if you have to turn this feature on.
So far, I'm assuming it won't be enforced by default and using the
"is interface" property to turn it on. Like I said, I could go either way
and the choice of property name just happens to go with what I feel an
interface is.
--
Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
