Dmitry Dorofeev writes:
> Hi all.
> Sorry if this idea|question has been discussed or has name which i don't
> know about.
>
> I am not very good at OO but I tried at least 2 times to develop with
> it though :-) Last time it was Java. The problem is that when i going
> to use some 'standard' class or 3d party class i'd rather to cut off
> all unnecessary methods (and may be even properies!), then adding my
> own.
Why do you want to cut off theirs?
> I know it kills inheritance but it is much more to my Perl habit of
> hacking code.
Yes, it quite kills inheritance. Say in your example (whose syntax I
will show in this footnote[1]) that you have:
sub foo(a $x) {
print $x.area;
}
Now if you give it a myclass, it's not really an a anymore, because it
doesn't behave like one. Which leads me to believe that you should be
using something besides inheritance.
> example:
>
> Class a {
> method getX;
> method getY;
> method size;
> method area;
> method move;
> }
>
> I'd like to write
>
> Class myclass : a {
> forget method area;
> forget method move;
> method put;
> }
>
> so methods getX, getY, size will be 'inherited'.
> Methods 'area' and 'move' will be not present in myclass at all!
> so
> $a = new myclass;
> $a.area()
>
> will return an error.
> At some level of inheritance methods area() and move() may be reimplemented
> again if required.
>
> I see few benefits
> 1. Much more flexible to build what programmers need. Becouse we have both
> 'joining' and 'breaking' around us in real life.
> 2. Inheritance diagrams may become less in size, showing only what
> programmer use or need in classes.
> 3. probably there are some optimization possibilities (especially for
> properties)
>
> i see some drawbacks
> 1. kills traditional OO mainstream, theory and books
> 2. hard to keep track both for 'added' methods and for 'killed' methods in
> mind.
> 3. hard to know if 'killed' method called from the other methods in the
> class. But that may be
> not a problem if we just declare forget blah, without affecting
> run-time.
So you're saying that if size called area, that area would be called as
though you hadn't forgotten it? Okay, you definitely don't want
inheritance.
It sounds like you're wanting inheritance for code reuse. The Perl 6
way to reuse code is with roles, but assuming that you either don't know
how to use roles, the 3rd party writer didn't use them, or you're in a
language without them (like Java), I would suggest aggregation:
class MyClass {
has A $.a; # turns out that "a" is a keyword in Perl 6
method getX() { $.a.getX }
method getY() { $.a.getY }
method size() { $.a.size }
method put() { ... }
}
The thing is, that when you inherit from a class, you expect the
subclass to behave like the superclass in some extended way (thus the
Java keyword C<extends>). Removing methods makes it so the subclass no
longer behaves like the superclass, because methods you'd expect to call
don't exist anymore.
That is not to say, of course, that Perl won't let you do it. It's
Perl, after all :-) [2]
> I am very interested what Perl gurus think about it. Even if you consider
> this as stupidiest idea ever.
> Which is probably true :-)
>
> -Dmitry Dorofeev.
[1] Your code, Perl6-ized:
> Class a {
> method getX;
> method getY;
> method size;
> method area;
> method move;
> }
class A {
method getX() {...}
method getY() {...}
method size() {...}
method area() {...}
method move() {...}
}
> I'd like to write
>
> Class myclass : a {
> forget method area;
> forget method move;
> method put;
> }
[2] Never, ever do this, but just in case:
class MyClass is A {
method put() {...}
method DISPATCH([EMAIL PROTECTED]) {
die "No such method: $DISPATCH" if $DISPATCH eq 'area'|'move';
.$DISPATCH([EMAIL PROTECTED]);
}
}
Luke
