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

[Loïc Hoguin]

On 01/25/2013 01:33 PM, David Goehrig wrote:
>
>
> On Thu, Jan 24, 2013 at 10:18 AM, Loïc Hoguin <essen@REDACTED
> <mailto:essen@REDACTED>> wrote:
>
>
>     Assume a variable Character. This variable contains everything about
>     the character. How do you best access and modify Character? The
>     answer must not involve the process dictionary, processes or message
>     passing. Today I have to write each access and modification
>     function. Or I can generate it, but either way I end up with
>     hundreds of functions in many modules.
>
>
> Assuming that "you're doing it wrong" and you make "doing this wrong" a

Am I? What is the right way then? Creating many processes isn't helping 
write my snippets any easier in Erlang, it just complicates things.

> the easiest way is nested proplists

Nope, it's still a pain to update.

> if you want to feel like you're doing something "object oriented":

I don't want to do something object oriented. I hate OO. I just want 
primitives to easily update deep data structures.

[...]

>
> But the entire notion of nested structures for this sort of design would
> be wrong in most languages as the exact semantics rely upon wether or
> not you are intending for just this instance of this Character's
> weapon's ability's cost to be modified, or you are modifying the cost of
> the ability across the game (due to ability being a reference to a
> shared data structure, or just intending all instances of this weapon to
> be modified (due to ability being a substructure of weapon itself AND
> weapon is a reference to a shared structure).
>
> In either of those two cases, this approach will fail entirely, as it
> will construct clean proplists and only modify the cost of this specific
> character's individual weapon's specific ability cost.

But modifying the cost of this specific character's individual weapon is 
exactly what we want! And it's exactly what is painfully hard to write 
in Erlang.

> Is very difficult to qualify within your assumptions, because we don't
> know the structural ramifications of the . operator.

Think of it as C structs and arrays for example. If I have a field in a 
struct in an array in a struct, and I want to update this field's value, 
it's a one liner in C, and many many lines in Erlang. Of course Erlang 
has immutable variables, but that doesn't prevent it to figure out at 
runtime what exactly we want to modify and return a copy of the struct 
with the field modified. This of course has a runtime cost, but it's 
irrelevant compared to how nicely small your program becomes and how 
fast you can write it.

> So there's a lot of ways to skin this cat based on the structure of how
> you hide your properties.

This isn't about hiding the properties, this is about the syntax for 
modifying these properties in the process where you hide them.

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