For a few weeks Ive been thinking about relation between objects  not especially OOPs objects. For instance in C++, were used to representing that by layering pointers or container of pointers in the structure that needs an access to the other object. If an object A needs to have an access to B, its not uncommon to find a B *pB in A.But Im not a C++ programmer anymore, I write programs using functional languages, and more especially in Haskell, which is a pure functional language. Its possible to use pointers, references or that kind of stuff, but I feel strange with that, like doing it the non-Haskell way.Then I thought a bit deeper about all that relation stuff and came to the point:Why do we even represent such relation by layering?I read some folks already thought about that (here). In my point of view, representing relations through explicit graphes is way better since it enables us to focus on the core of our type, and express relations later through combinators (a bit like SQL does).By core I mean that when we define A, we expect to define what A is made of, not what it depends on. For instance, in a video game, if we have a type Character, its legit to talk about Trait, Skill or that kind of stuff, but is it if we talk about Weapon or Items? Im not so sure anymore. Then:data Character = {    chSkills :: [Skill]  , chTraits :: [Traits]  , chName   :: String  , chWeapon :: IORef Weapon -- or STRef, or whatever  , chItems  :: IORef [Item] -- ditto  }sounds really wrong in term of design to me. Id rather prefer something like:data Character = {    chSkills :: [Skill]  , chTraits :: [Traits]  , chName   :: String  }-- link our character to a Weapon using a Graph Character Weapon-- link our character to Items using a Graph Character [Item] or that kind of stuffFurthermore, when a day comes to add new features, we can just create new types, new graphs and link. In the first design, wed have to break the Character type, or use some kind ofwork around to extend it.What do you think about that idea? What do you think is best to deal with that kind of issues in Haskell, a pure functional language?
Relation between objects
haskell;relationships