[erlang-questions] Parameterized module initialization

[Joe Armstrong]

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