3 ms·

> Behavior is much like an class/object: it has public methods, internal state, polymorphism (via message passing) > a Behavior runs in it's own process This d

by tomn 7y ago

> Behavior is much like an class/object: it has public methods, internal state, polymorphism (via message passing) > a Behavior runs in it's own process This doesn't sound right; a behaviour is just a set of functions to be implemented in a 'callback module'; you seem to be talking about processes and modules. I agree with your points though.

lliamander 7y ago
> This doesn't sound right; a behaviour is just a set of functions to be implemented in a 'callback module'; Going back, I see that you are right: the Behavior is technically the common pattern that is shared across specific processes. Is there a name for a process that is defined in a callback module? And really, this complaint about confusing modules spans to more than just callback modules. Most processes define both the client and server functions in the same module. For small modules it's not too big a deal, but even then it is very difficult for someone new to the language to learn how follow the flow of data. Dave Thomas has some interesting ideas about this and other problems, but as I don't do Erlang programming professionally at the moment I haven't had time to really dig in deep.
- toast0 7y ago
  > Is there a name for a process that is defined in a callback module? I don't think there really is. Where I was working, we would just say this process is a gen_server (or whatever), as if it was a type of process, but this is more of an emergent property of the environment, than a named property. If enumerating the processes, you can guess a process is a gen_server based on erlang:process_info(initial_call, Pid), but that's not definitive because it could have started as something else, then used gen_server:enter_loop to become a gen_server, or started as a gen_server and then become something else. Naming the behavior the same as the module, and including client apis and server and the behavior in the same module is legitimately confusing as well; although, all that being in the same place can be nice, too.

by tomn 7y ago

lliamander 7y ago

> This doesn't sound right; a behaviour is just a set of functions to be implemented in a 'callback module'; Going back, I see that you are right: the Behavior is technically the common pattern that is shared across specific processes. Is there a name for a process that is defined in a callback module? And really, this complaint about confusing modules spans to more than just callback modules. Most processes define both the client and server functions in the same module. For small modules it's not too big a deal, but even then it is very difficult for someone new to the language to learn how follow the flow of data. Dave Thomas has some interesting ideas about this and other problems, but as I don't do Erlang programming professionally at the moment I haven't had time to really dig in deep.

toast0 7y ago
> Is there a name for a process that is defined in a callback module? I don't think there really is. Where I was working, we would just say this process is a gen_server (or whatever), as if it was a type of process, but this is more of an emergent property of the environment, than a named property. If enumerating the processes, you can guess a process is a gen_server based on erlang:process_info(initial_call, Pid), but that's not definitive because it could have started as something else, then used gen_server:enter_loop to become a gen_server, or started as a gen_server and then become something else. Naming the behavior the same as the module, and including client apis and server and the behavior in the same module is legitimately confusing as well; although, all that being in the same place can be nice, too.