Wave,
It is much more than passing a parameter. You can pass an object that the receiver can expect will provide fields and methods according to the interface definition.
Ordinarily a function or method parameter will be of some type and the receiver can operate on that type or any type that is derived from it.
With an interface this changes to the receiver being able to operate on any type that implements the interface.
And yes, in this example you could derive everything from a single type that defines virtual methods then override with the actual methods but the point with interfaces is that you don't have to. There is no good design reason that I can see to have a tank, a bird and a road laying machine all derive from some super type when just about everything else that they do will be different.
Add other capabilities like refueling, weapons control and saving/loading object state. It becomes difficult to impossible to come up with a sensible hierarchy but remains manageable to design it using interfaces. Remember that you may want to give non-navigable types like a fixed gun-turret weapons control and just about everything including game settings and windows will need saving/loading object state.
Then you want to add stealth mode for some types and allegiance and build cost and experience etc. And pass all of these types around to common draw, file and AI routines.
Then somebody develops a custom skinning manager that can take an object if it supports the ISkinnable interface.
The blitz_object code fragment is C or C++ which is the language in which a lot of the internals of BM is written. Amazingly and quite helpfully a lot of these internals are exposed to you if you go looking.
This particular bit is how the 'down cast' operates.
Suppose the the type hierarchy is:
type A
type B extends A
type C extends B
type D extends C
You have an instance of D called myD.
You want to cast myD to type B for example. Or even just see if myD is derived from it.
What the code does is take your instance as parameter o and the desired type as parameter t. It checks the type of o to see if it is the same as t (it isn't but if it was it would return the instance).
If the type is not the same then it walks up the hierarchy to check the next higher object/type (the 'super'). Eventually it hits the matching type B and returns the object.
If it ran right up the hierarchy without finding a match then it returns a null.
---------------------------------------------------------
Dreamora,
Originally you said:
btw: I found something very strange today in one of BRLs modules.
There you see that he calls a Typename with a value (TMax2DGraphicsDriver (g)) to create a type. But so far I'm not able to understand what it does there or how to use. If I try it, I always get the message "Illegal subexpression for object cast" ...
So somehow constructor with values seem to be possible.
You did not point to a module but quoted 'TMax2DGraphicsDriver (g)' so I went looking. There is no such text but I did find 'TMax2DGraphics(g)' in module max2d.bmx and showed the relevant section then explained that it is a cast not a constructor.
Perhaps I didn't find the right bit of code ?
If you can really provide the module and function name for this bit of code that shows a constructor with a parameter then please do so. I'd be very interested to see it.
It is Ok to make a mistake but pretty immature to get snotty and attempt to misrepresent the situation when your little misunderstanding gets corrected.
It is much more than passing a parameter. You can pass an object that the receiver can expect will provide fields and methods according to the interface definition.
Ordinarily a function or method parameter will be of some type and the receiver can operate on that type or any type that is derived from it.
With an interface this changes to the receiver being able to operate on any type that implements the interface.
' Define an interface which gives the method signatures but does not provide their implementation interface INavigate --method TakeShortestRoute(from:Place, to:Place) --method TakeSafestRoute(from:Place, to:Place) --method TakeScenicRoute(from:Place, via:Place, to:Place) ' Define types that implement the interface type TShip implements INavigate --method ShortestRoute(from:Place, to:Place) { ' Some clever code appropriate to ship navigation} etc type TBird implements INavigate --method ShortestRoute(from:Place, to:Place) { ' Some clever code appropriate to bird navigation} etc type TTank implements INavigate --method ShortestRoute(from:Place, to:Place) { ' Some clever code appropriate to tank navigation} etc type TRoadBuilder INavigate --method ShortestRoute(from:Place, to:Place) { ' Some clever code appropriate to a machine and crew building a road} etc type TPilot --method PlanCourse(INavigate ride) ' Expects something that can navigate by one of several means and applies logic to decide which route is best
And yes, in this example you could derive everything from a single type that defines virtual methods then override with the actual methods but the point with interfaces is that you don't have to. There is no good design reason that I can see to have a tank, a bird and a road laying machine all derive from some super type when just about everything else that they do will be different.
Add other capabilities like refueling, weapons control and saving/loading object state. It becomes difficult to impossible to come up with a sensible hierarchy but remains manageable to design it using interfaces. Remember that you may want to give non-navigable types like a fixed gun-turret weapons control and just about everything including game settings and windows will need saving/loading object state.
Then you want to add stealth mode for some types and allegiance and build cost and experience etc. And pass all of these types around to common draw, file and AI routines.
Then somebody develops a custom skinning manager that can take an object if it supports the ISkinnable interface.
The blitz_object code fragment is C or C++ which is the language in which a lot of the internals of BM is written. Amazingly and quite helpfully a lot of these internals are exposed to you if you go looking.
This particular bit is how the 'down cast' operates.
Suppose the the type hierarchy is:
type A
type B extends A
type C extends B
type D extends C
You have an instance of D called myD.
You want to cast myD to type B for example. Or even just see if myD is derived from it.
What the code does is take your instance as parameter o and the desired type as parameter t. It checks the type of o to see if it is the same as t (it isn't but if it was it would return the instance).
If the type is not the same then it walks up the hierarchy to check the next higher object/type (the 'super'). Eventually it hits the matching type B and returns the object.
If it ran right up the hierarchy without finding a match then it returns a null.
---------------------------------------------------------
Dreamora,
Originally you said:
btw: I found something very strange today in one of BRLs modules.
There you see that he calls a Typename with a value (TMax2DGraphicsDriver (g)) to create a type. But so far I'm not able to understand what it does there or how to use. If I try it, I always get the message "Illegal subexpression for object cast" ...
So somehow constructor with values seem to be possible.
You did not point to a module but quoted 'TMax2DGraphicsDriver (g)' so I went looking. There is no such text but I did find 'TMax2DGraphics(g)' in module max2d.bmx and showed the relevant section then explained that it is a cast not a constructor.
Perhaps I didn't find the right bit of code ?
If you can really provide the module and function name for this bit of code that shows a constructor with a parameter then please do so. I'd be very interested to see it.
It is Ok to make a mistake but pretty immature to get snotty and attempt to misrepresent the situation when your little misunderstanding gets corrected.