[erlang-questions] Elixir Protocols in Erlang & a Strange Warning

Kaveh Shahbazian <>
Mon Dec 16 21:24:17 CET 2013


Not really; I did not want to simulate OO in Erlang (BTW Erlang feels
perfectly OO to me; maybe in a very irrelevant way).
I just used C# sample to convey something similar to what I wanted to do -
which as I've mentioned in other email turned out to be a horrible sample.

I wanted to do this:

test(V) ->
    X = ?protocolX(V),
    X:act1(),
    X:act2(),
    % ...
    X:actN(SomeArguments),
    OtherThings().

Which as Bob described is not a good (or rather great) idea to use in
Erlang for one that calling functions on tuples add more levels of
redirection that can affect the performance in not so pleasant ways.

I am not an Erlang guru but I really like the environment and currently I
lean toward Elixir more than Erlang; because it has macros! And I know I
should not macros on a daily basis, but just knowing they are there and
possible is ultra comforting.

Kaveh Shahbazian
“Walking on water and developing software from a specification are easy if
both are frozen.”
― Edward Berard
<http://goo.gl/ZZ2TMu>
<http://stackoverflow.com/users/54467/kaveh-shahbazian>


On Mon, Dec 16, 2013 at 6:38 AM, Richard A. O'Keefe <>wrote:

>
> On 13/12/2013, at 7:31 PM, Kaveh Shahbazian wrote:
>
> > I wanted to write something like ((IStringer)object).ToString() (in C#)
> in Erlang.
>
> Can you make it a little bit clearer exactly what it is you
> need to do?
>
> There is a fundamental distinction between the way
> something like
>         object.toString()
> works in OO languages
>         to_string(Object)
> works in Erlang:
> - in the OO languages the "object" is in charge of what
>   .toString() means
> - in Erlang, the _function_ is in charge of what to_string()
>   means.
> > Then I came up with this idea/code in Erlang - which is nice enough to
> me like:
> >
> > ?stringer(my_val):to_string().
> >
> > 1 - Why nobody use this or promote things based on stateful modules in
> Erlang?
>
> Where do you get "stateful" from?  An Erlang parameterised module
> is a *value*.
>
> In this case, "my_val" is *still* not in charge of what to_string
> does.
>
> In any case, one way to begin to understand parameterised modules
> in Erlang is to start by thinking of
>
>         -module(foo, {X,Y,Z}).
>         -export([to_string/0]).
>         to_string() ->
>
> as if it were something not entirely unlike
>
>         -module(foo).
>         -export([new/1,to_string/1]).
>         new({X,Y,Z}) -> {foo,X,Y,Z}.
>         to_string(This = {foo,X,Y,Z}) -> ...
>
> There is, in short, no fundamental theoretical or practical difference
> between
>
>         stringer(my_val):to_string()
>
> and
>
>         stringer:to_string(my_val).
>
> Anything you can do with the first you can CERTAINLY do with the second.
>
> If you want to simulate OO in Erlang,
> (1) lie down until the feeling passes off;
> (2) if the condition persists, see a doctor (of CS);
> (3) if the cure is unsuccessful,
>         represent an "object" by a tuple
>         {tag,Funs,Data}
>     where Funs is a tuple of functions shared by a number of
>     instances (yes, it's a vtable), and write
>
>         to_string(Obj = {_,{...,TS...},...}) ->
>             TS(Obj).
>
> I am deadly serious about (1).
>
> When you using ((IStringer)object).to_string()
> you are literally saying
>
>         I don't know and I don't care what object
>         is as long as it conforms to the IStringer
>         interface.  I don't know and I don't care
>         what the .to_string() method does as long
>         as it has the right kind of arguments and
>         results; it could reformat my hard drive,
>         it could send threatening messages to the
>         president of the USA, it could burn down
>         the local hospital, I really really DON'T
>         CARE.
>
> If that's not what you mean, then perhaps you'd better write
> your code another way, even in C#.  Any time you pass around
> something with pluggable behaviour, ideally you need a strong
> type-AND-EFFECT system that lets you limit the damage that
> can be done, or at the least you need comments saying what is
> supposed to be allowed.
>
> I'm actually serious about (2) as well: see if you can find
> a copy of "Why Joe Hates OO" by our very own Joe Armstrong.
>
> (For the record, I am not an anti-OO bigot.  I have spent way
> too much of my time building a Smalltalk system I'm generally
> quite pleased with to be _that_.  But I have come to dread
> not knowing what an argument will do if I poke it, especially
> in a multithreading context.)
>
> > (OTP aside and from talking to some Erlangers they did not know that
> actually OTP is built around this!
>
> They didn't know it because it isn't true.  For a long time Erlang
> didn't have parameterised modules, then it did as an experiment,
> and now it doesn't again.  OTP managed without them and does again.
>
>
> > So really there is a need to change how Erlang is being taught and
> promoted. It's possible that I am confused.).
>
> If you find yourself struggling to do things the language X way
> in language Y, it's generally a better to look for an _idiomatic_
> way to solve the underlying problem in language Y than to try to
> warp language Y into acting like language X.  Just recently I've
> seen a horrible example of a Prolog system being warped to be
> more like JavaScript, to the applause of people who haven't
> thought about the benefits of being able to use other Prolog
> systems as well...
>
> As one example, it's not unknown for an Erlang module that
> defines a data type to export a format/1 and maybe format/2
> for converting an instance to a string or writing it to a
> stream.  Using
>
>         snorkelwhacker:format(Monster)
>
> makes it clear that Monster is supposed to be the kind of thing
> that the snorkelwhacker module knows about; this might be one of
> several things.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131216/7030a986/attachment.html>


More information about the erlang-questions mailing list