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

[Vlad Dumitrescu]

Hi all,

There are two schools of thought here. One would like to put all the data
in a giant nested data structure and the other would like to split it up
into the smallest possible parts. I think that was what David G. hinted at
before, but he didn't put the final dot over the i.

Having a single huge immutable nested data structure would require the kind
of access patterns exemplified by "character.current_weapon.score", but is
not without other kind of problems. I can think of three important ones.
(1) You would need another syntax for "character.bag_item(12).supply" or
"character.friend('Bilbo').weapon", for example. This is alleviated by
Joe's suggestion, where one can use all kind of selectors. (2) All updating
must be done from the root or in several steps, so i f I have
X=Character.weapon, X.score=10, I need to remember to Character.weapon=X.
(3) Changing the implementation of an item to another data structure might
be problematic without changing all the call sites.

On the other side, that David described, one could have a character
process, a weapon process, a bag process and so on. Then, using a construct
that Joe suggested oh so many years ago, you could write
Character!!weapon!!score to retrieve it and Character!!weapon!!{score, 30}
to set it. The !! operator is a 'rpc' and is conceptually a send followed
by a receive. The processes will be effectively implement active objects.

My feeling is that the latter option is more Erlang-y, but it may be a
matter of taste.

best regards,
Vlad



On Fri, Jan 25, 2013 at 4:08 PM, Joe Armstrong <erlang@REDACTED> wrote:

> Manipulating nested records is a pain - how about this?
>
> Assume we have three records
>
> -record(top, {a::#one{},     b::#two{},  c::#three{}  }).
> -record(one, {x::#foo{},  y::#bar{} })
> -record(foo, {p,q,r}).
> and I want to unpack the p field from a variable X containing a top
> record.
>
> I don't want to write
>
>   #top{a=#one{x=#foo{p=P}}} = X
>
> this is messy and error prone
>
> This should do the job
>
>     P = extract_from(X, top,p)
>
> A compile transform could figure out the code to make. In this case the
> tag p has a unique path from the top root. In the case where the required
> tag is not unique, we'll need to "hint" the path.
>
> We just give the parse transform enough hints to figure out
> the path at compile time. We should get a error if the path does not
> uniquely
> specify the element.
>
> Cheers
>
> /Joe
>
>
>
>
> On Fri, Jan 25, 2013 at 2:07 PM, Darach Ennis <darach@REDACTED> wrote:
>
>> Hi guys,
>>
>> There is a problem here. Any reasonably sized or structured erlang
>> application
>> requires records, despite the grody record syntax. The alternative? Big
>> hairy unstructured
>> clods of tuple and lists and things? Worse. Unmaintainable in and of
>> itself. Hard to pattern
>> match. Had to manipulate. Hard for humans to grok whilst reading without
>> squinting your
>> brain hard and quizzically at the terminal ...
>>
>> Unlike the matrix, it's not blonde, brunette or a redhead ... It's
>> something else! ;(
>>
>> So they're needed? Yes. Use by choice? No. And that's the problem.
>>
>> I secretly hope for for something better to come along. A big gnarly
>> unstructured
>> and frequently accessed tuple would be fine, for example, if there was
>> some kind
>> of tuple path expression language... like XML has XPath? Jackpot.
>>
>> So maybe frames aren't needed at all. Maybe frames would be nice. Perhaps
>> we
>> just want to reach out and touch the a subset of tuples of lists of
>> tuples of lists of
>> tuples of ... I'm pretty sure with or without frames that solves 80% of
>> the need for me.
>>
>> The other 20%? -  Native support for Kaysian transforms and other natural
>> conveniences
>> for efficient slicing, dicing, filtering and merging.
>>
>> I'm not sure record or any other syntax is actually the problem.
>>
>> Also, the nice thing about adding something like an XPath like thing for
>> tuples?
>> It doesn't break existing applications. It's backward compatible. It's
>> forward
>> migratable. No new syntax because an expression can be a plain old list of
>> binary (string).
>>
>> So, we maybe xmerl_xpath already has 99% of what's needed...
>>
>> Cheers,
>>
>> Darach.
>>
>>
>>
>> On Fri, Jan 25, 2013 at 12:25 PM, Loïc Hoguin <essen@REDACTED> wrote:
>>
>>> On 01/25/2013 12:10 PM, Loïc Hoguin wrote:
>>>
>>>> Let me tell you something about yourself.
>>>>
>>>
>>> I have been told this bit can be considered offensive in English, it
>>> isn't meant to be.
>>>
>>>
>>> --
>>> Loïc Hoguin
>>> Erlang Cowboy
>>> Nine Nines
>>> http://ninenines.eu
>>> ______________________________**_________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130125/f4c337a0/attachment.htm>