[erlang-questions] Parameterized module initialization

[CGS]

Hi,

With the chance to be considered "ugly", I've been using the solution given
here by Joe along with some others (using list instead of tuple - Erlang is
good at list manipulation and, by the way, doesn't the great tail recursion
use this kind of variable shadowing? i see no ugliness in it; list of
tuples - feels like working with JSON's; record - working with server
state; nested records - complex states, "one state to rule them all";
string hiding the variables - easy to convert into/from data transfer
stream over a tcp connection; and maybe others). Each approach has its own
advantages and disadvantages. The solution given by Joe is close to
defining a state of a gen_server or whatever (pretty often in documentation
one can find a state defined by a record). Maybe when Erlang will have the
records replaced by something else, this practice will be obsolete, Joe's
solution gets +1 from me.

That's my 2c opinion.

CGS





On Tue, Jun 26, 2012 at 4:56 PM, Joe Armstrong <erlang@REDACTED> wrote:

> On Tue, Jun 26, 2012 at 3:14 PM, Vlad Dumitrescu <vladdu55@REDACTED>
> wrote:
> > Hi,
> >
> > On Tue, Jun 26, 2012 at 2:53 PM, Joe Armstrong <erlang@REDACTED> wrote:
> >> There is an undocumented way of doing this (which one day will become
> standard)
> >> Suppose we define X as follows:
> >>> X = {mod1, a,b,c}.
> >> {mod1, a,b,c}.
> >> X is now an instance of a parameterised module. if we now call the
> >> function X:func1(x,y) then what actually gets called is the function
> >> mod1:func1(x,y,{mod1,a,b,c})
> >
> > I hope that you are expressing some form of sarcasm, Joe.
>
> No - there is no sarcasm implied.
>
> I like this mechanism.  This way of hiding additional data is very
> flexible.
>
> I've used this in several programs, and the resulting code is easy to
> understand. This nice thing is that using this you can make very nice
> client APIs. For example, for string processing you might say
>
>             Str = {ansi_string, "abc"},         or
>             Str = {utf8_string, "u+1234"}
>
> And then when you call
>
>             Str:substr(1,4)
>
> Get the correct behaviour depending upon the underlying string type ie
> either ansi_string:substr(1,4,{ansi_string,"abc"}) or
> utf8_sting:substr(1,4,{utf8_string, "u+1234"} ) will be called
>
> If you write a program where strings might be in latin1, or utf8 or
> something else you'd still
> have to tag the string (as in say {latin1, "abc"}) so you knew what
> the encoding was and still
> have to call different modules depending upon the tag. This is what
> the above mechanism does
> so it's very nice for hiding the mess in polymorphic interfaces.
>
> /Joe
>
>
>
>
> >
> > If I may use such language, it is horrible. Just as we got (almost)
> > rid of {M,F} to the benefit of proper function references, are we
> > going to get another kludge? A proper module reference is the way to
> > go here. Then there are plenty of nice things that can be supported in
> > a clean way.
>
>
>
>
> >
> > best regards,
> > Vlad
> _______________________________________________
> 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/20120627/11c2558f/attachment.htm>