[erlang-questions] If you are homesick for object.selector

[Loïc Hoguin]

On 01/24/2013 01:39 PM, Jesper Louis Andersen wrote:
>
>
> On Jan 24, 2013, at 3:37 AM, Loïc Hoguin <essen@REDACTED> wrote:
>
>> Character.current_weapon.ability.points_req
>
> I think this is the major reason. It allows you to "chain" access to deep data. Note that this is a "projection" operation. You project out an element from the pair. The other solution, which is more Erlang-idiomatic is to match on the object and decode needed fields. But this solution is problematic when you need to access deep object data.
>
> What you really need is composition of lenses, and a neat syntax for doing so. That is a composable access language for obtaining data deep in structures. The usual chaining projection does *not* work in Erlang because you don't know the type of the object at compile time, unless you have the record name to help you. For that to work, you need frames, or something which works the same.
>
> On the other hand, when people access deep data like that, I often become concerned. Why is data not readily available to them but has to be dug up from far below the depths of a structure? Is this the right representation? There is overhead in following pointers and you can't always cache access over function boundaries.

Are you suggesting that #character *duplicates* fields from both #weapon 
and #ability? Then you'd just end up with #character having hundreds of 
fields, which is as unmanageable and even less readable, especially if 
some share a common name, like #character.attack_pts and #weapon.attack_pts.

Hierarchy helps clarity. "Character.current_weapon.ability.points_req" 
is the direct transcription of "Character's current weapon's special 
ability's required points". (Completely made up, but would apply to 
various games I know. Heck it'd be even worse for management games.)

Not talking about pointers there, you don't need them for enabling all this.

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu