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

[Garrett Smith]

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.

> 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!

Garrett