forbid field name conflict in class hierarchy

[spir]

On Mon, 15 Nov 2010 09:45:26 -0800
Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Monday, November 15, 2010 06:00:33 Manfred_Nowak wrote:
> > Jonathan M Davis wrote:
> > > Having public fields shadow each other is problematic.
> > 
> > Detecting a problem requires having a model.
> > What does your model look like?
> 
> You're going to have to be more specific in your question than that. It's not at 
> all clear what you're asking.
> 
> Public and protected functions use polymorphism. Public and protected member 
> variables do not. So, it becomes error prone to have public or protected member 
> variables which shadow each other. It becomes easy to end up in a situation 
> where you're not using the one that you think that you're using - especially 
> when code gets changed.

True. There is an issue in the static model of OO, with class hierarchy: methods are dispatched, data fields are not. If there are "same" fields (same name & type), then the one of the superclass is used. The only safe alternative would be to have runtime dispatch of fields like of methods, but this is indeed costly.

(This "staticity" also leads to the side-effect that one cannot write generic routines which variables (from parameters or result of calls) have the superclass as declared type but also use subclass fields. To be able to do it, I end up adding subclass fields to the superclass. I know it's wrong, but haven't found the right way to do it. I don't feel like "downcasting" most variables in most routines.)


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com