Quantcast

origin of handle_info/2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

origin of handle_info/2

Xavier Noria
A curiosity,

Where does the `handle_info` callback name come from? The name does not suggest what the method is invoked for to me.
 
I wonder if there is a historical background behind that name, or perhaps "info" reflects usage in a way that I fail to see.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: origin of handle_info/2

Richard Carlsson-3
It's "info" in the sense of "any other messages to this process, that are not recognised as special OTP framework messages". When you use a function like gen_server:call(...), the OTP libraries wrap your message in a way that lets the receiving server process see that it is a part of the OTP framework and redirects it to the standard callbacks like handle_call() or handle_cast(). If you just send a message to the gen_server process with the ! operator, it will not have the right wrapper, and will be dispatched to handle_info(). Typical uses of info messages are timeouts and other "note to self" style messages.


        /Richard

2017-03-16 16:33 GMT+01:00 Xavier Noria <[hidden email]>:
A curiosity,

Where does the `handle_info` callback name come from? The name does not suggest what the method is invoked for to me.
 
I wonder if there is a historical background behind that name, or perhaps "info" reflects usage in a way that I fail to see.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: origin of handle_info/2

Xavier Noria
On Thu, 16 Mar 2017 at 23:11, Richard Carlsson <[hidden email]> wrote:

It's "info" in the sense of "any other messages to this process, that are not recognised as special OTP framework messages". When you use a function like gen_server:call(...), the OTP libraries wrap your message in a way that lets the receiving server process see that it is a part of the OTP framework and redirects it to the standard callbacks like handle_call() or handle_cast(). If you just send a message to the gen_server process with the ! operator, it will not have the right wrapper, and will be dispatched to handle_info(). Typical uses of info messages are timeouts and other "note to self" style messages.


Yes, that is the way it works, but "info" doesn't convey that meaning to me. Does it to you?

I wondered if maybe historically it had a smaller contract where "info" was a natural choice and with time the contract was relaxed up to accepting anything but calls and casts.
--
Sent from Gmail Mobile

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: origin of handle_info/2

Richard Carlsson-3
No, I think it's more to do with the fact that the original authors were not native English speakers, and thought "info" was a good enough shorthand for "any other stuff that someone sends us".


        /Richard

2017-03-16 23:57 GMT+01:00 Xavier Noria <[hidden email]>:
On Thu, 16 Mar 2017 at 23:11, Richard Carlsson <[hidden email]> wrote:

It's "info" in the sense of "any other messages to this process, that are not recognised as special OTP framework messages". When you use a function like gen_server:call(...), the OTP libraries wrap your message in a way that lets the receiving server process see that it is a part of the OTP framework and redirects it to the standard callbacks like handle_call() or handle_cast(). If you just send a message to the gen_server process with the ! operator, it will not have the right wrapper, and will be dispatched to handle_info(). Typical uses of info messages are timeouts and other "note to self" style messages.


Yes, that is the way it works, but "info" doesn't convey that meaning to me. Does it to you?

I wondered if maybe historically it had a smaller contract where "info" was a natural choice and with time the contract was relaxed up to accepting anything but calls and casts.
--
Sent from Gmail Mobile


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: origin of handle_info/2

Per Hedeland
On 2017-03-17 10:58, Richard Carlsson wrote:
> No, I think it's more to do with the fact that the original authors were not native English speakers, and thought "info" was a good enough shorthand for "any other stuff that someone sends us".

Well, some of the original authors were (are) native English speakers:-)
- but in any case, what's wrong with "info"? Some process, or the VM,
sent us a message - seems like a reasonable assumption that there is
some relevant information in it, but that's pretty much the only
assumption that can be made.

Maybe the OP has a term in mind, that would be better at conveying the
meaning "any other stuff that someone sends us"?

--Per

>         /Richard
>
> 2017-03-16 23:57 GMT+01:00 Xavier Noria <[hidden email] <mailto:[hidden email]>>:
>
>     On Thu, 16 Mar 2017 at 23:11, Richard Carlsson <[hidden email] <mailto:[hidden email]>> wrote:
>
>         It's "info" in the sense of "any other messages to this process, that are not recognised as special OTP framework messages". When you use a function like gen_server:call(...), the OTP
>         libraries wrap your message in a way that lets the receiving server process see that it is a part of the OTP framework and redirects it to the standard callbacks like handle_call() or
>         handle_cast(). If you just send a message to the gen_server process with the ! operator, it will not have the right wrapper, and will be dispatched to handle_info(). Typical uses of info
>         messages are timeouts and other "note to self" style messages.
>
>
>
>     Yes, that is the way it works, but "info" doesn't convey that meaning to me. Does it to you?
>
>     I wondered if maybe historically it had a smaller contract where "info" was a natural choice and with time the contract was relaxed up to accepting anything but calls and casts.
>
>     --
>     Sent from Gmail Mobile
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: origin of handle_info/2

Tony Rogvall-2
I vote for handle_random_stuff
:-)

/Tony

> On 17 mar 2017, at 12:36, Per Hedeland <[hidden email]> wrote:
>
> On 2017-03-17 10:58, Richard Carlsson wrote:
>> No, I think it's more to do with the fact that the original authors were not native English speakers, and thought "info" was a good enough shorthand for "any other stuff that someone sends us".
>
> Well, some of the original authors were (are) native English speakers:-)
> - but in any case, what's wrong with "info"? Some process, or the VM,
> sent us a message - seems like a reasonable assumption that there is
> some relevant information in it, but that's pretty much the only
> assumption that can be made.
>
> Maybe the OP has a term in mind, that would be better at conveying the
> meaning "any other stuff that someone sends us"?
>
> --Per
>
>>        /Richard
>>
>> 2017-03-16 23:57 GMT+01:00 Xavier Noria <[hidden email] <mailto:[hidden email]>>:
>>
>>    On Thu, 16 Mar 2017 at 23:11, Richard Carlsson <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>        It's "info" in the sense of "any other messages to this process, that are not recognised as special OTP framework messages". When you use a function like gen_server:call(...), the OTP
>>        libraries wrap your message in a way that lets the receiving server process see that it is a part of the OTP framework and redirects it to the standard callbacks like handle_call() or
>>        handle_cast(). If you just send a message to the gen_server process with the ! operator, it will not have the right wrapper, and will be dispatched to handle_info(). Typical uses of info
>>        messages are timeouts and other "note to self" style messages.
>>
>>
>>
>>    Yes, that is the way it works, but "info" doesn't convey that meaning to me. Does it to you?
>>
>>    I wondered if maybe historically it had a smaller contract where "info" was a natural choice and with time the contract was relaxed up to accepting anything but calls and casts.
>>
>>    --
>>    Sent from Gmail Mobile
>>
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: origin of handle_info/2

Alex S.
In reply to this post by Per Hedeland

> 17 марта 2017 г., в 14:36, Per Hedeland <[hidden email]> написал(а):
>
> On 2017-03-17 10:58, Richard Carlsson wrote:
>> No, I think it's more to do with the fact that the original authors were not native English speakers, and thought "info" was a good enough shorthand for "any other stuff that someone sends us".
>
> Well, some of the original authors were (are) native English speakers:-)
> - but in any case, what's wrong with "info"? Some process, or the VM,
> sent us a message - seems like a reasonable assumption that there is
> some relevant information in it, but that's pretty much the only
> assumption that can be made.
>
> Maybe the OP has a term in mind, that would be better at conveying the
> meaning "any other stuff that someone sends us"?
>
> --Per
>
Well, it *is* most often used for timeouts and DOWN’s which are kind of informational.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: origin of handle_info/2

Xavier Noria
In reply to this post by Per Hedeland
On Fri, Mar 17, 2017 at 12:36 PM, Per Hedeland <[hidden email]> wrote:

Well, some of the original authors were (are) native English speakers:-)
- but in any case, what's wrong with "info"? Some process, or the VM,
sent us a message - seems like a reasonable assumption that there is
some relevant information in it, but that's pretty much the only
assumption that can be made.

But that is what _any_ function does, right? You get a message, that contains some data. You could have called the callback "do_stuff" for that matter!

Maybe the OP has a term in mind, that would be better at conveying the
meaning "any other stuff that someone sends us"?

Yes, I would expect a name more in the line of:

    handle_rest
    handle_internal
    handle_timeout (split interface for the timeout use-case)
    ...

Something that resonates closer to "this is called for any other message than a call or cast".

Hey, not bikeshedding the callback name at all uh? but was wondering if it could have had a historic path from a narrower use-case that then widened with time. Or maybe some rationale for the name that I could be missing.

If there is no such historic background... that is fine, curiosity solved :).

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: origin of handle_info/2

Roger Lipscombe-2
In reply to this post by Per Hedeland
On 17 March 2017 at 11:36, Per Hedeland <[hidden email]> wrote:
> Maybe the OP has a term in mind, that would be better at conveying the
> meaning "any other stuff that someone sends us"?

As an also-native English speaker, I vote for "handle_gubbins" :)
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: origin of handle_info/2

Brady Powers
"handle_other"
"handle_all"
"handle_else"

The above, in my opinion as a native english speaker, portray the intent of "handle_info" better than the actual name. Now I'm not very good at naming, so my suggestions could be equally confusing to others, but I find it hard to support "handle_info" as a good name. 


On Friday, March 17, 2017 8:20 AM, Roger Lipscombe <[hidden email]> wrote:


On 17 March 2017 at 11:36, Per Hedeland <[hidden email]> wrote:
> Maybe the OP has a term in mind, that would be better at conveying the
> meaning "any other stuff that someone sends us"?

As an also-native English speaker, I vote for "handle_gubbins" :)

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: origin of handle_info/2

dmercer
In reply to this post by Roger Lipscombe-2
Native English speaker here, and while I think `handle_info` is just fine, I think `handle_message_not_handled_by_handle_call_or_handle_cast` would be more descriptive.

On Fri, Mar 17, 2017 at 7:20 AM, Roger Lipscombe <[hidden email]> wrote:
On 17 March 2017 at 11:36, Per Hedeland <[hidden email]> wrote:
> Maybe the OP has a term in mind, that would be better at conveying the
> meaning "any other stuff that someone sends us"?

As an also-native English speaker, I vote for "handle_gubbins" :)
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: origin of handle_info/2

Alex S.
Hi, non-native English speaker here, and `handle_plain` | `handle_other` wouldve been more sensible I guess?..

Way too late to break compatibility tho.
20 марта 2017 г., в 18:52, David Mercer <[hidden email]> написал(а):

Native English speaker here, and while I think `handle_info` is just fine, I think `handle_message_not_handled_by_handle_call_or_handle_cast` would be more descriptive.

On Fri, Mar 17, 2017 at 7:20 AM, Roger Lipscombe <[hidden email]> wrote:
On 17 March 2017 at 11:36, Per Hedeland <[hidden email]> wrote:
> Maybe the OP has a term in mind, that would be better at conveying the
> meaning "any other stuff that someone sends us"?

As an also-native English speaker, I vote for "handle_gubbins" :)
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Loading...