[erlang-questions] If you are homesick for object.selector
Mon Jan 28 18:40:51 CET 2013
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...
>>> 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
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
> 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!
More information about the erlang-questions