<div>Hi,</div><div><br></div><div>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.</div>
<div><br></div><div>That's my 2c opinion.</div><div><br></div><div>CGS</div><div><br></div><div><br></div><div><br></div><br><br><div class="gmail_quote">On Tue, Jun 26, 2012 at 4:56 PM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Jun 26, 2012 at 3:14 PM, Vlad Dumitrescu <<a href="mailto:vladdu55@gmail.com">vladdu55@gmail.com</a>> wrote:<br>

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