forbid field name conflict in class hierarchy

[spir]

On Mon, 15 Nov 2010 12:32:07 -0800
Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Monday 15 November 2010 11:44:11 spir wrote:
> > 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.)
> 
> I'm not sure that pure OO would even allow for public variables. [...]
> That just screams that it shouldn't 
> be a public member variable (and truth be told, public member variables are 
> generally considered bad practice except in simple objects - which would 
> generally be structs in D).
The issue does not require fields to be public. The same problem happens when writing methods of the class hierarchy.

> I do really 
> have to wonder what you're doing though that you feel the need to access 
> subclass fields using super class references. [...] And if you really need the subclass type, then you 
> should be using the subclass type, not the super class type

For instance a nested/recursive structure analog to a tree. There may be leaf nodes (only element), branch nodes (only subnodes), both, special ones with different kinds of values, etc...
Custom routines may need to use other methods to explore a branch's children, get its leaves, filter, or whatever. All these tool methods are generic (meaning must use the top Node type), but the custom routines need to access subtype-specific fields. Thus, "down-casting" all the time.
I find it tiresome (and bug-prone, because sometimes the absence of a fields seems not caught, for any reason), so I add fields to the top type.

> Also, return types 
> are covariant, so you can return a subclass from overridden functions instead of 
> the super class like the function which was overridden does. Maybe that would 
> help. It would depend on what exactly you're doing though.

Yes, but doesn't this mean I should override all tool methods for all subtypes, just so that I don't need to down-cast their results (in the routines that use them)?
I think a better solution would be that the compiler does not prevent us to use subtype fields. Why does it do so? In the worst case, if the field does not exist, we'll get an error, anyway.

> - Jonathan M Davis

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

spir.wikidot.com