[erlang-questions] New module syntax and semantics?

[Juan Jose Comellas]

Yes, that's also an option and in fact I am already doing it, because the
event message also has all the information corresponding to a channel, and I
keep this information as a separate tuple. The main benefit I see with
parameterized modules is that I would be able to expose a generic interface
for channel events and freely change the underlying representation without
having to modify the modules that use them. It's not a huge benefit, but I
would certainly use this feature if I had some certainty that it could
suddenly disappear from the next version of Erlang.


On Tue, Jul 1, 2008 at 9:06 PM, Christian S <chsu79@REDACTED> wrote:

> 2008/7/1 Juan Jose Comellas <juanjo@REDACTED>:
> > The good thing about this feature is that it provides a way to have an
> > "encapsulated" record replacement.
>
> > The code that receives the events is unnecessary cumbersome because it
> needs
> > to work with a record within a record. If this was encapsulated within a
> > parameterized module, it would become much cleaner.
>
> Nested records are not nice, no. For the record:
>
> make_stuff() ->
>  #fs_channel_event{extra=#fs_channel_answer_event{write_codec_name=rot13}}.
> set_stuff(Ex) ->
>  Ex2 =
> Ex#fs_channel_event{extra=(Ex#fs_channel_event.extra)#fs_channel_answer_event{read_codec_name=leetspeak}}.
>
> So the verbose syntax to do the above is what you want to avoid.
>
>
>
> Did you consider using an approach like the following instead?
>
> AnswerEvent = {#fs_channel_event{}, #fs_answer_event{}}
> HangupEvent = {#fs_channel_event{}, #fs_hangup_event{}}
>
> It's easy to deconstruct a tuple in pattern matching. You dont get the
> nesting above.
>
> make_stuff() ->
>  {#fs_channel_event{}, #fs_channel_answer_event{write_codec_name=rot13}}.
> set_stuff({A, B}) ->
>   {A, B#fs_channel_answer_event{read_codec_name=leetspeak}}.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080702/e44f2f75/attachment.htm>