Godmar Back wrote:
>
> >
> > * Virtual methods are supported but you have to use the 'virtual' and
> > 'override' keywords - a bit ugly. Otherwise methods are treated as
> > non-virtual. My guess is that they are trying to avoid the problem
> > that Java has with nearly everything being a virtual method, and the
> > resulting performance issues. However, a static C# compiler should be
> > able to devirtualize everything since there's no dynamic class loading.
> >
>
> Actually, this choice is something I very much agree with.
> I think that Java got it wrong when it made "virtual" the default.
> The performance issues you mention are the least of my concerns.
I can't agree with you. this's the basic of OOP. you have to choose
the right name for a function and have tobe a good specification of
the classes and functions (which is not a bad thing anyway:-)
> The primary problem is that virtual methods are error-prone. They
> can easily break base classes if a subclass that overrides a method
> does not implement the contract of the overridden method 100%, which
> frequently happens. Especially in closed-source (or bytecode only)
> base systems where you extend classes in the "programming by difference"
> paradigm such mistakes are hard to impossible to track down.
yes if you dont read the documentation of the package what you get
just try to find out what may it do...
it sounds me like a 1st od 2nd year student at the university, who wanna
make a good gui and heard about java and from the class and function name
and same sample code try to write his own nice "program".
> Granted, having to declare a function "virtual" does not guard against
> such mistakes. But at least it puts up a warning sign that tells the
> implementor to be especially careful when defining that method's semantics,
> and it tells the caller to not rely on hidden knowledge about their
> implementation.
I don't think it's a good design patter to be a class with 2 function
with same signature (name and argument) and one in the base class and one
in the drived. I think it something which is _real_ error-prone!
> In essence, it's an issue of deciding what's the normal, common case,
> which requires less attention, and what is the less common case which,
> because of its semantic implications, needs conscientious attention
> when used.
the normal case if you use the same signature for a function that you
would like to override the default behavior.
-- Levente
"The only thing worse than not knowing the truth is
ruining the bliss of ignorance."
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
