[erlang-questions] Deriving records from one another?

[Dmitry Kolesnikov]

Hello,

Yes, the composition (nested records) is one way to solve the issue.
I would not use two records #shared{} and #inner{}
> -record(state { shared :: #shared{}, inner :: #init{} | #etc{} }).


I would compose #shared{} record directly into state.
> -record(state { shared :: #shared{}, field1, field2, ...}).


you might want to isolate all #shared{} specific code to dedicated module so that all process will re-use same code base.

Best Regards, 
Dmitry

On 23 Jun 2014, at 16:49, Roger Lipscombe <roger@REDACTED> wrote:

> I'm probably thinking too OO by calling it "deriving", but here's the problem:
> 
> OTP handlers (gen_server, etc.) take a State parameter. You can stick
> anything in here, but generally I've been using a #state record, and
> keeping a bunch of values in it.
> 
> Now I'd like to actually start representing *state* with the State[1].
> That is, I'd like to be able to match on #init, #ready,
> #expecting_key, #whatever records. This will hopefully make the code
> easier to read, and means that my record doesn't have to contain
> fields for stuff that's not relevant in the given state.
> 
> However, some of the fields *are* shared between states, so my
> question is (in OO terms) how do I derive record types from
> each-other?
> 
> I've thought about using a tuple: {Shared, State} when Shared ::
> #shared{}, State :: #init{} | #etc{}
> That might be hard to read in matches, though, maybe.
> 
> I've thought about using a container record:
> -record(state { shared :: #shared{}, inner :: #init{} | #etc{} }).
> 
> Are there any good solutions[2] to this problem? Or are there better
> ways to do what I'm trying to do?
> 
> Cheers,
> Roger.
> 
> [1] No, I don't think that gen_fsm is the answer at this point.
> Interesting suggestion, though, thanks.
> [2] Still on R16, so I can't use maps, but I'm still interested in how
> they might help, if at all.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions