Hi Andrew, I don't think there are any direct obstacles to doing the same with extensible records, but I think extensible records also have no advantages, produce code that is IMHO slightly harder to read, and could introduce some problems in larger codebases.
Note that OOP game engines I've worked with (Unity most notably, but also bits of Cry and Unreal) prefer encapsulation over inheritance. In Unity a game object is a collection of components (Collision, AI, etc.), instead of objects inheriting the individual components. This is why I felt the proposed solution to be better. A possible counter-argument would be that the nature of Elm's records means that multiple inheritance (nested extension of records) is not an issue as would be in OOP [1]. However, with extensible records, you cannot reuse the same field name across the different components - or, more precisely, when you do it, compiler will either merge the fields (if they have the same type) and your components will likely not work the way you expect or the compiler will produce confusing error messages if the fields have the same name but differ in type. [1] With type aliases, (Positioned (WithAI x) ) is equivalent to (WithAI (Positioned x)) Martin On Wednesday, 4 January 2017 20:46:44 UTC+1, Andrew Radford wrote: > > Martin are there any pros/cons to using extensible records for the game > entities? i.e closer conceptually to an OOP model where an entity might > inherit Collision/Physics properties from a common base class? > > Andrew > > >>> -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
