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

[Garrett Smith]

On Mon, Jan 28, 2013 at 12:49 PM, Loïc Hoguin <essen@REDACTED> wrote:
> On 01/28/2013 06:40 PM, Garrett Smith wrote:
>
>> On Mon, Jan 28, 2013 at 11:08 AM, Loďc Hoguin <essen@REDACTED> wrote:
>>>
>>> On 01/28/2013 02:57 AM, Garrett Smith wrote:
>>>>
>>>>
>>>> On Sun, Jan 27, 2013 at 7:23 PM, Robert Virding
>>>> <robert.virding@REDACTED> wrote:
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>>
>>>>>>
>>>>>> From: "Richard O'Keefe" <ok@REDACTED>
>>>>>>
>>>>>> This is _so_ on-topic...
>>>>>>
>>>>>> http://thedailywtf.com/Articles/Ancestors.aspx
>>>>>
>>>>>
>>>>>
>>>>> Think how much more difficult to read it would have been if you had to
>>>>> include the record names. :-)
>>>>
>>>>
>>>>
>>>> For the benefit of those who didn't click the link, it contains this
>>>> function in C#:
>>>>
>>>> private void MouseMove(object sender, MouseEventArgs e)
>>>> {
>>>>      (sender as
>>>> PictureBox).Parent.Parent.Parent.Parent.Parent.GetType();
>>>> }
>>>>
>>>> After seeing that, I'm convinced Erlang record syntax is one the
>>>> language's best features. If other languages had such a tax, this sort
>>>> of thing would be held in check.
>>>>
>>>> Call it a sin tax.
>>>
>>>
>>>
>>> Except that's completely different from what we'd like to have.
>>>
>>>   *  We do not want a parent() mechanism.
>>>   *  We do not want pointers or references.
>>>   *  We do not want to be able to call functions.
>>>
>>> Also note that with regards to Erlang, it's *not* syntax that prevents
>>> this
>>> kind of behavior, but processes and message passing. Your process can
>>> only
>>> handle so much.
>>>
>>> We just need a data structure and associated syntax that's convenient for
>>> semi-deep data structures, where the fields are clearly defined (like a
>>> record), except field resolution would be performed at runtime to allow
>>> chaining and thus easier pattern match and/or modification. And
>>> ironically
>>> it could also easily solve the record upgrade problem, because you'd have
>>> the fields at runtime.
>>
>>
>> Isn't this close to frames? I'm somehow under the impression that
>> Ericsson has a "maps" (or similarly named feature) that's near
>> release.
>>
>> Unless I've missed something, perhaps a status update on the "frames"
>> problem might bring this thread to a happier conclusion.
>
>
> Close. But not quite (at least in its current form).
>
> Here we are talking about a data structure with fixed fields, like records,
> which allows amongst other things type checking (dialyzer and runtime).
>
> Frames would be "better than nothing" but at the last EUC the only thing
> related was a benchmark of hash implementations to see which one is best for
> eventual inclusion. Sounds like it's the last thing that should be done
> though, make it work, make it pretty, make it fast. Many people would be
> fine with just the first two (and that's what I'll do in my experiments).
>
>
>>> Data manipulation is something that can make or break projects, and is
>>> the
>>> reason why I stopped one of mine, because all the solutions you can think
>>> of
>>> are light years away of what can be achieved with very little language
>>> support.
>>>
>>> Of course, language support means first acknowledging there is indeed a
>>> problem, and I am not surprised to hit walls here, especially in the "you
>>> just need functions" crowd (who don't seem to be aware of how nice
>>> pattern
>>> matching in function clauses and guards are). So I'll experiment on my
>>> end
>>> for a while and if it turns out that it works I might just use this new
>>> language for the previously mentioned project. That'd certainly motivate
>>> me
>>> enough to reboot it.
>>
>>
>> I still think you want a relational model for your gaming use case.
>> SQLite + memory db FTW!
>
>
> Half of this data is temporary to the current session. The other half is
> tied to the first half, and only needs to be retrieved and saved at key
> intervals. A relational database fits the storage of the permanent data. It
> however again only complexifies the manipulation. It would also likely not
> scale much. A game has a lot of things happening per player and you need one
> or the other value available for use or to send it to the client when needed
> and not 2 seconds later.

I'm talking about 1 in-memory db per process. I have no idea how this
would perform -- I'm *mainly* trying to see how long we can make this
thread :)

Nonetheless, if I had a complex data structure that was subject to
change (new features, etc.) I'd be tempted to use a relational model.
Erlang + native SQLite bindings might be quite fast -- I have no idea,
but I'd give it a try and measure.

Of course then you'd *really* need a functional facade -- and how
beautiful would that be?

Garrett