[erlang-questions] New module syntax and semantics?

[Juan Jose Comellas]

In this case I would not necessarily create a module per type of event, but
even if I did, I don't see it as a problem. Each event has several functions
associated to them that that are part of the event interface. This
functionality, coupled with behaviours could even provide something like the
concept of an abstract class.

I would probably do what Mochiweb does for the accessors of an HTTP request
(src/mochiweb_request.erl int the mochiweb package). The
mochiweb_request:get/1 function looks like this:

get(socket) ->
    Socket;
get(method) ->
    Method;
get(raw_path) ->
    RawPath;
get(version) ->
    Version;
get(headers) ->
    Headers;
get(peer) ->
    case inet:peername(Socket) of
    {ok, {Addr={10, _, _, _}, _Port}} ->
        case get_header_value("x-forwarded-for") of
        undefined ->
            inet_parse:ntoa(Addr);
        Hosts ->
            string:strip(lists:last(string:tokens(Hosts, ",")))
        end;
    {ok, {{127, 0, 0, 1}, _Port}} ->
        case get_header_value("x-forwarded-for") of
        undefined ->
            "127.0.0.1";
        Hosts ->
            string:strip(lists:last(string:tokens(Hosts, ",")))
        end;
    {ok, {Addr, _Port}} ->
        inet_parse:ntoa(Addr)
    end;
[...]

This makes it really easy to deal with the data contained in a request, and
you never have to worry about how it is stored in the tuple.

My only issue with the current syntax is that the variables from the
parameterized module seem "magical", as you can't tell where they came from
by just looking at the function.



On Tue, Jul 1, 2008 at 10:11 PM, Richard A. O'Keefe <ok@REDACTED>
wrote:

>
> On 2 Jul 2008, at 8:59 am, Juan Jose Comellas wrote:
>
> -record(fs_channel_event, {..lots..,extra}).
> -record(fs_channel_answer_event, {..several..}).
> -record(fs_channel_hangup_event, {..several..}).
>
>  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.
>>
>
> I don't quite see how it would, unless, no, you _couldn't_
> be thinking of making a module instance for each channel?
>
> It's certainly not clear that so heavy a sledgehammer is
> needed for this nut.  Can you provide an example of the
> 'unnecessarily cumbersome code' so we can see if it can
> be clarified another way?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080702/8fdc8955/attachment.htm>