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

[ok@REDACTED]

>>
>> Loïc Hoguin wrote:
>> (1) Please let's have a real concrete example of about 1 page,
>>      not imaginary one-liners, with names that turn out to be
>>      not as intention-revealing as they look.
>
> It's a real concrete example.

The one and only example I have seen so far
was a one-liner involving an imaginary game.
If it isn't an imaginary game, my apologies.
But it was still a one liner, and without any
context to make it interpretable.

> I'm sure you can imagine other examples.

I don't want imaginary examples.  Like I said,
please let's have about a page of code, with enough
context to make it intelligible.

> Or perhaps you are going to tell me you never had to manage big amounts
> of related data in Erlang? (Wouldn't surprise me.)

I've had to manage sufficient data for a single run
to take days.

>>      Are we debating whether Person~name, with the same fundamental
>>      limitation as field access in C or Java or ML, is a really big
>>      improvement over Person#person_name?
>>
>>      Or has the idea crept in that Person.name might run complex code?
>
> *Data*. Not code. Access. Update. That's all that's needed.

Sigh.  But does *CARRYING OUT* that access or update involve
running complex code?  I mean, fetching a field from a *record*
doesn't count as complex code, but fetching an entry from a
'dict' does count as running complex code, way beyond what
Person#person.name could do.


> Let me tell you something about yourself.
>
> You are confronted with the problem of wasting a lot of time writing
> basement level code to access and update deep values.

If confronted with that task, I will refuse to do it.
I will _definitely_ do something to generate that code
automatically, just as we have leex and yecc and other
tools for generating code.

> The
> DSL still maps to functions which needs to access and update these
> values, and that code is still painful to write.

Yes, but using a DSL ***means*** that you do not write that code
more than once.

> Your next step is to
> think "Great! Let's generate all that code then!". Now you got three
> problems, and you better hope to have not made any error when writing
> that code generator or you'll waste a lot more time.

I write small-scale task-specific code generators a LOT.
It's not quite as easy as falling off a log, but it's
easier than, say, getting a complex regular expression right.
Yes, I make mistakes when I do this, and yes, I have to test
a fair bit.  But most of this is testing I would have had to
do *anyway* and mistakes I would have made *anyway* except
that instead of a mistake being made once, found by one test,
and fixed with a single fix, there would have been dozens of
copies.


> Speaking of time,
> by the time you get to that point the PHP developer has already long
> finished his bug-free implementation of the same code and is moving on
> to other tasks.

Does there exist such a thing as a bug-free implementation of
anything in PHP?

In all seriousness, I use small-scale code generation BECAUSE
IT SAVES ME TIME.  Coding time, testing time, debugging time.

> That's still besides the point. If it's not Character.inventory it's
> State.character and State.inventory. Doesn't make updating any easier.

Again, I think we have strayed from the original path,
which had nothing to do with updating and everything to
do with the perceived verbosity of Person#person.name.

If you want ease of updating, there's no shame in using F#.