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

[Loïc Hoguin]

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.

But regardless, you're still just proposing solutions that increase the 
complexity of the work one has to do. I know there's currently no good 
solution for this in Erlang, you don't need to convince me.

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