| F# for game development |
I've got along well with inheritance for a long time, but this was not peace. Inheritance was preparing, in the dark, cowardly, waiting to byte me. And it just did that!
In my last post, I presented a method to detach libraries from external assemblies and let applications take responsibility for the "linking".
The key was to use interfaces to shadow the API of the external assemblies. Sadly, it falls apart when the API being shadowed, say XNA, relies on inheritance to connect to the user's code.
Take GameComponent, for example. Users are expected to define
In my last post, I presented a method to detach libraries from external assemblies and let applications take responsibility for the "linking".
The key was to use interfaces to shadow the API of the external assemblies. Sadly, it falls apart when the API being shadowed, say XNA, relies on inheritance to connect to the user's code.
Take GameComponent, for example. Users are expected to define
a type that inherits from GameComponent, overriding a number of methods (Initialize, Update and Draw, typically).
It would be nice if one could declare that XNA provides a type GameComponent with abstract methods (the syntax is made up, that's not valid ML or F#):
signature Xna =
type GameTime
type GameComponent with
abstract new : unit -> unit
abstract Initialize : unit -> unit
abstract Update : GameTime -> unit
abstract Draw : GameTime -> unit
Using the...(Read whole news on source site)
It would be nice if one could declare that XNA provides a type GameComponent with abstract methods (the syntax is made up, that's not valid ML or F#):
signature Xna =
type GameTime
type GameComponent with
abstract new : unit -> unit
abstract Initialize : unit -> unit
abstract Update : GameTime -> unit
abstract Draw : GameTime -> unit
Using the...(Read whole news on source site)




