On Mon, May 02, 2005 at 06:49:10PM +0200, Thomas Sandlaß wrote:
> David Storrs wrote:
> >Let's move this away from simple types like Str and Int for a moment.
>
> If you consider them simple...
When compared to
"arbitrary-class-that-was-defined-by-
arbitrary-programmer-of-
arbitrary-and-unknown-skill-level"
then yes, I consider them to be extremely simple.
> >Tell me what this does:
> >
> >class Tree {
> > method bark() { die "Cannot instantiate a Tree--it is abstract!" }
> >}
> >class Birch {
> > method bark() { return "White, papery" }
> >}
> >class Oak {
> > method bark() { return "Dark, heavy" }
> >}
> >class Dog {
> > method bark() { print "Woof, woof!"; return "bow wow" }
> >}
>
> Four 'pure' classes so far.
Dog is not pure according to the definition of "pure class" that I
know (no side effects in any method, constructor, or subclass). Maybe
'pure class' means something else to you?
> >class AlienBeastie isa Tree isa Dog {}
>
> Here you get an error/warning of a composition time conflict between
> &Tree::bark and &Dog::bark.
So that I'm clear, is this your opinion/preference or is it based on
material from the SEAs? If the latter, could you point me to the
relevant passage?
> My preferred
> syntax for multiple inheritance is the junctive notation 'is Tree & Dog'
> for subclassing because it nicely allows for superclassing with
> 'is Tree | Dog'.
Again, so that I'm clear--this is your preference, and is not derived
from any authoritative source, correct?
> This might dispatch correctly for 'pure' Trees, Dogs etc.
> but not for your mixed classes above.
As I noted above, Dog is not 'pure' by the definition I know so I'm
not sure what to make of this statement.
--Dks
