I guess my point is if you’re
referring to everything by its subtype anyway (in your example as Compositeand
not MovieClip) then it doesn’t matter if your method is attachMovie or
lb_attachMovie, it’s still going to be specific to the subclass and your
code can call it just as easily with the new name. The superclass version
of the method isn’t involved at all unless you specifically call up to it.
If any code refers to the object as a MovieClip only the superclass method is
going to be called, even if you overload it in the subclass. So whileit
would be nice if it used the same name as the superclass for readability, you’re
not gaining anything technically.
If you have an example where the inability
to name the method the same truly breaks polymorphism that’d be
helpful. Otherwise we can certainly acknowledge that this can be
inconvenient (though it does prevent you from mistakenly thinking your subclass
method will be called when it won’t) but I’m not sure I see it as a
real bug.
Matt
From: foreeldo2001
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 02, 2005
12:52 PM
To: [EMAIL PROTECTED]
Subject: [flexcoders] Re: Subclass
method signatures *must* match supercla ss methods?
Hey Matt,
That's a great answer and you're absolutely
correct. In most cases,
our client classes would refer to the Dog class as
a mammal and simply
expect a reference to the super class in anytyped
arguments. But
obviously, there are places where we want todeal
with a dog as a Dog
(otherwise there would be only Mammals and Dogs
wouldn't exist...) and
you would have classes that need to have the
greater specificity. This
is the crux of OOP, is it not?
For a more specific example, I would like to
extend MovieClip, with
some other, more specific Composite object.
Everything in my
application will reference the more detailed
composite object. In
order to work for everyone, I would like to
override all of the
MovieClip's methods with one change - the datatype
that they expect
and return. (Let's say Composable for example)
This cannot be done in flex unless we use
Composition. Composition
would be completely unacceptable because it would
double both - Object
instantiation (System initialization CPU
requirements) and Object
Count. (memory footprint). The only other hack
would be to rename all
of the methods with some other, less meaningful
and certainly less
well-known name. Probably with some horrible
prefix, like
"lukes_attachMovie" or
"lb_attachMovie"...
Java handles this problem by allowing method
overloading. This is (I
think) a completely acceptable and dare I say,
great way to handle the
problem. It allows us to be both general *and*
specific. Overloading
does have some drawbacks in that it leads to
pretty verbose classes
and can at least occasionally lead to quite a bit
of duplicate code.
Ultimately, there is no way we're going to get
method overloading
because we don't have runtime type-checking.I'm
actually not even
asking for method overloading becuase (I think) it
would have a
dramatic (negative) effect on both performance and
the player download
size.
What I'm really expecting is for the FLEX compiler
to ignore this
situation since it is an extremely important(I
would argue -
critical) part of Object-Oriented development.
Would you agree with the following:
a) It's an issue that prospective and current
users should be acutely
aware of.
b) Macromedia should be notified so that
subsequent releases can
contain some form of fix - or change.
