Field inheritance problem...
BlitzMax Forums/BlitzMax Programming/Field inheritance problem...
| ||
| Hi, To me this seems like a bug or at least unwanted behavior: Type TBase
Field name:String
Method New()
name = "something"
EndMethod
Method SetName(s:String)
name = s
EndMethod
EndType
Type TExt Extends TBase
Field name:String
EndType
Local e:TExt = New TExt
Print "~q"+e.name+"~q"
e.SetName("hello??")
Print "~q"+e.name+"~q"
Local b:TBase = New TExt
Print "~q"+b.name+"~q"
b.SetName("hello??")
Print "~q"+b.name+"~q" |
| ||
| This is no bug and and works as intend If you create a field of the same name on an extended type, it will actually stealth the original field and create a new field with that name. But you can still access both. Self.name will return its name super.name will return its base class name If it is really usefull to have this behavior is a different question. Especially with reflection on the horizont, it looks like this behavior is far more troublesome than actually desireable. |
| ||
| This is known as 'hiding' if you 'hide' a field in this way you may access it as Dreamora states but you can also do so by casting, this way you can access hidden fields outside of an object. E.g. Print TBase(e).name |
| ||
| Hi, Yes, it may be technically valid, but is it logically and practically useful? I don't think so, but maybe someone has a scenario where it might come in handy? |
| ||
| No, its hardly ever useful, however thats the way Overridding works. If we said it was a bug, and we took out overriding, I for one would moan about it when it came to methods and functions. Well its just the same for Fields, if you dont want it overridden, simply dont redefine it in extended types. (That might sound a bit curt, no offence ment if it does) |
| ||
| Obviously overriding is extremely useful for methods and functions, but for fields? I don't know... |
| ||
| Oh, I agree its of dubieous use, and every example Ive seen of it on these forums have basicly been a waste of memory, with the original field simply being hidden/lost memory. However Im sure if we wanted to we could come up with some use for it, and if someone was already using it for that.. well they wouldnt be happy if we changed it. I for one am willing to say thats its not a bug, but rather an underapreahiated feature. (And let face it, the main reason it looks like a bug, is because you didnt expect it, but now you do... etc) |
| ||
| This discussion has taken place in the Java community, and like here there are advocates for and against it. My take on it: It is generally accepted, good OO programming practice that fields should only be accessed outside of an object declaration through getter and setter methods. Fields should generally be thought of as 'private' data. Field hiding allows a user to subclass an object without having to worry about identifier conflicts. For example we might not necessarily know a base class contains the fields name$, x%, or y% because they are either implicitly or explicitly (not possible in bmax) private. These identifiers are very common and this is where 'hiding' is useful. |
| ||
| > It is generally accepted, good OO programming practice that fields should only be accessed outside of an object declaration through getter and setter methods. Fields should generally be thought of as 'private' data. Uh-oh, yes, this is how the Java community would see it. But if you start a discussion with Pyhonistas about it, you will hear -exactly- the opposite: "We're all adults here and don't need privates and setters and getters." And, usually, Pythonistas will ask you -why- you think you need privates and setters in the first place. The interesting thing is that usually nobody has a really good answer for it except for that it is a commonly accepted convention. Especially in Java this can become an interesting discussion, since the language does not even allow operator overloading. (Usually one of the arguments for setters is that you -might- do something special with your object's properties when assigning a value to them; more or less like you would do something special when you overload their operators.) Anyway, it's just an interesting academic discussion. ;-) |
| ||
| I'm just curious as to why you would ever want to redefine a field? I mean, true, there's limited use for overriding fields but there's also limited use for redefining the field in the first place. |
| ||
| @any pythonistas, What if you have a field called size:float. This field is the size in mm of an object. In your program you have used this field with myobject.size. You now want to have an 'imperial' option so you have fields size_mm and size_inch. You *could* change each time you used myobject.size throughout your entire program and/or code it with an 'if' but it would be messy. If you use the myobject.getsize() method then you only need to change the getsize method to return the required size... or have I missed something? |
| ||
| I think that, as long as we don't have private fields in types, it is a good thing. Imagine you're creating a new inherited class, called ExtendedTList. then imagine you class has a filed called Counter. Ok, then imagine you sync mods with the official brl and pub servers and, surprise, the TList class has now a field called Counter. It would be a shame if this could make your code crash or impossible to compile without changes. So, as long as there are not private fields, I think this is a very good way to make things. In fact, it would be even better if we could overload functions and methods. Obviously, we will have to wait and see how does this fit with the reflection stuff. |
   |