NewsForumsCodeLogsGallerySpecsSearch

Why does this happen? [inheritance]

BlitzMax Forums/BlitzMax Beginners Area/Why does this happen? [inheritance]

GW(Posted 2007) [#1]
The bmax docs imply that derived types are looked at first for access, But only for methods??
The debugger shows P as having 2 _value1 fields, which i understand, but why is the child field bypassed but not the method?
Strict
Framework brl.basic 

Type Parent
	Field _Value1 = -9999
	
	Method GetValue1()
	End Method
	
	Method SetValue1(val)
	End Method
	
	Function CreateChild:Child()
		Return New Child 
	End Function
End Type

Type Child Extends Parent
	Field _Value1 = 1111
	
	Method GetValue1()
		Return _Value1
	End Method
	
	Method SetValue1(Val)
		_Value1 = Val
	End Method
End Type



Local P:Parent
P = Parent.CreateChild()

Print P._Value1		'<-- returns -99999

Print P.GetValue1()	'<-- returns 1111



grable(Posted 2007) [#2]
Because Fields can be "overridden" as well.
So each type gets a separate copy of the field.

What determines which field to access is the type of the object being used at the time.


Dreamora(Posted 2007) [#3]
and if you need to get the parrents field, you can use super.fieldname or with reflection you could even get parent.parents field etc.


GW(Posted 2007) [#4]
and if you need to get the parrents field, you can use super.fieldname or with reflection you could even get parent.parents field etc.


I'm actually looking to access the child field.
logically, you would think that the default field would be the child and super would be needed to access the parent.
Wrapping the request in a method is a workaround, but I'm looking to find out why the behavior is inconsistent.


grable(Posted 2007) [#5]
Its not realy inconsistent when you consider the contexts each piece of code is runing in.

Local p:Parent
p.Value ' context is Parent
p.GetValue() ' context is Child 
TChild(p).Value ' context is Child



H&K(Posted 2007) [#6]
Whilst I was about to agree with you grable, I have changed my mind during the act of posting, and have eddited as such.

First let me say that I always thought that this sort of "Field Hidding" was stupid, and I still do, so in my mind its a stupid thing to do full stop

However, if I have cast a child object to a parent object if I call overridden fields or methods then I should either get Both the child field and child method or Both the parents fields and parents methods

Now I do override Methods, and I would expect to get the Childs methods even when its cast as a parent, as I said I dont override Fields (Cos its stupid), but if I did then consitency would require that I would get the childs fields.

(Clarify: Just cos I think Its stupid to do, doesnt mean that it is stupid to do)

(But it is)


Who was John Galt?(Posted 2007) [#7]
I'm with H&K. I would avoid this kind of programming, but the behaviour is inconsistent and should be fixed.


GW(Posted 2007) [#8]
I agree.
IMO it throws a big monkey wrench in polymorphism or your forced to use getters and setters for everything.


Gabriel(Posted 2007) [#9]
I also consider it inconsistent and I'm consistent in finding it inconsistent because I asked the same question quite some time ago and got the same answer.

It's very illogical to have one behaviour with fields and a different behaviour with methods. The problem is, that this far down the road, if Mark changed it, a lot of existing code would break. So I ruefully admit that it should probably stay as it is now, for the sake of people who have done what the language forces them to do.


FlameDuck(Posted 2007) [#10]
I'm with H&K. I would avoid this kind of programming, but the behaviour is inconsistent and should be fixed.
I agree. And by "fixed" I mean "the compiler should throw an error, and refuse to compile if you try this kind of stupid shit".


Who was John Galt?(Posted 2007) [#11]
LOL. The duck doesn't mince words, does he!


Dreamora(Posted 2007) [#12]
I would be happy if the compiler handled methods similar to that.

Why?
Because then it would not "overload" (bm can not do that, thus "") methods but redeclare and you could make create functions that actually give back an instance of this type not of one of the parent types because you are not allowed to redefine its return type.


Brucey(Posted 2007) [#13]
It is a bit confusing, isn't it?
Print Child(P)._Value1	'<-- returns 1111


Although I don't understand why you would want to define the same Field name in both a class and its subclass anyway. I see that as a flawed design.


QuietBloke(Posted 2007) [#14]
I never have the same field name in a child type.
In my mind the child is extending the parent and gives the option to add additional fields and to replace methods to allow it to behave differently.
Creating a duplicate field in my mind is crazy.. your basically saying the child has the same variable defined twice.. you cant do that in the parent type and Id be just as happy if the compiler threw a 'variable defined more than once' error if I ever tried to do something like that.