4 ms·
I really tried to follow here but I just don't get it. Having a "become" concept in the language/framework seems pretty arbitrary. The whole "become" example in
by vladimirralev 10y ago
I really tried to follow here but I just don't get it. Having a "become" concept in the language/framework seems pretty arbitrary. The whole "become" example in erlang is just a language demo. You would usually have subtle variations of this same code with various different intents and it would be too obscure to define each separately. For example some "become"-s would have context state, or they will be temporary, or for the purpose of pooling the underlying process/actor data structure. Just "become" is not an appropriate name or abstraction in most real world cases.
- lostcolony 10y agoOh, agreed, the original example Joe has is just a language demo. But the ability to change one set of receives for another (that is, "this process listens for messages of type A, and in this one case, changes to start listening for messages of type B", which both Erlang and Scala can do just fine (again, my point was just that something you can do out of the box in Erlang, required a special keyword in Scala, which led to someone familiar with Scala to think you could not do it in Erlang) can be useful. I posted on someone else's comment in this thread with a real world example I had, where I had to change what my actor was listening for.