Dreamora, The first thing I did was to go look for it but unfortunatle I didn't find it.Tell me where or post, and I'll look at it.
PGF, ok I'm starting to get it. I do really want interfaces in Bmax. I especially see the gain when using external modules. And to extend a type is not an option in many cases because a type can only extend one other type. And that's the limit I don't like. Because wouldn't an abstract type (if a type could extend several types) be like an interface then? Any type could implement it and it's functions? Wouldn't "extend multiple" be better? Because then I could do the INavigate interface from an non-abstract type and by that have default-methods and I would only need to override those that I want to be unique for my Tank,Car,Ship. I assume an Interface is like an blueprint your type can use.
Now I got an idea for an workaround considering your last example =) and I hope what it will give the same result with a slightly longer implentation time. Let's say you have an abstract Type INavigate with some methods and variables and such.
Any type could incorporate it in a field. Type TBird Field Nav:INavigate.
When you got that and you want to pass the object to the pilot: Function Pilot( N:INavigate ) then you go
Pilot(Bird.Nav) and the pilot has access to all Navigation functions for Bird. The downside is that you have to make several derivied versions of navigate, one for TBird, one for TTank, one for TShip... Which would result in one navigate function for each type that implements the navigate protocol.
Now it this case the INavigation Type field Nav in Bird would not reach the birds X,Y and such. Therefore you have to add a Get Method to Navigate which could in this case accept a TMoveObject or using Var for X,Y. It would be longer but it seems doable and the result seems to me to be quite similar, wouldn't it?
I'll try to put together an example on this.. brb [EDIT - seems liek I don't ;) ]
PGF, ok I'm starting to get it. I do really want interfaces in Bmax. I especially see the gain when using external modules. And to extend a type is not an option in many cases because a type can only extend one other type. And that's the limit I don't like. Because wouldn't an abstract type (if a type could extend several types) be like an interface then? Any type could implement it and it's functions? Wouldn't "extend multiple" be better? Because then I could do the INavigate interface from an non-abstract type and by that have default-methods and I would only need to override those that I want to be unique for my Tank,Car,Ship. I assume an Interface is like an blueprint your type can use.
Now I got an idea for an workaround considering your last example =) and I hope what it will give the same result with a slightly longer implentation time. Let's say you have an abstract Type INavigate with some methods and variables and such.
Any type could incorporate it in a field. Type TBird Field Nav:INavigate.
When you got that and you want to pass the object to the pilot: Function Pilot( N:INavigate ) then you go
Pilot(Bird.Nav) and the pilot has access to all Navigation functions for Bird. The downside is that you have to make several derivied versions of navigate, one for TBird, one for TTank, one for TShip... Which would result in one navigate function for each type that implements the navigate protocol.
Now it this case the INavigation Type field Nav in Bird would not reach the birds X,Y and such. Therefore you have to add a Get Method to Navigate which could in this case accept a TMoveObject or using Var for X,Y. It would be longer but it seems doable and the result seems to me to be quite similar, wouldn't it?
I'll try to put together an example on this.. brb [EDIT - seems liek I don't ;) ]