|
|
|
|
Type of net:getnameinfo() is specified in the source file, and the one prevailing in the docs is as below:-
| -spec getnameinfo(SockAddr, Flags) -> {ok, Info} | {error, Reason} when | | SockAddr :: term(), | | Flags :: name_info_flags() | undefined, | | Info :: name_info(), | | Reason :: term(). |
Currently, the type is SockAddr :: term(), and could have been SockAddr :: socket:sockaddr().
I think fixing it in the source at L221 should fix it in the documentation as well. But please let me know if it doesn't.
However, I am myself confused about the way the type is specified, so thought I will discuss first before opening a PR.
It is not the net:getnameinfo/1 that I am confused, but about the net:getnameinfo/2. I don't understand the usage of ifndef and else while specifying this type specification. If you could please point me to a place where I can understand these 2 better. I don't want to make wild guesses here while I am working through the foundations of Erlang.
It could have been simpler had this specification been written like below, even though whatever "ifdef" is doing out there is to be taken into consideration:- | SockAddr :: socket:sockaddr() | term(), | | Flags :: name_info_flags() | undefined, | | Info :: name_info(), | | Reason :: term() |
Please let me know if there is any misconstrusion on my part.
Thanks and Regards Nalin Ranjan
|
|
|
Hi,
It is possible to configure (and build) otp *without* socket (esock) support.
That is what the ifdef'ing is about. Eventually, when socket is properly
official, this will be removed.
Regards,
/BMK
From: erlang-questions <[hidden email]> on behalf of Nalin Ranjan <[hidden email]>
Sent: Tuesday, January 26, 2021 1:12 PM
To: Erlang-Questions Questions <[hidden email]>
Subject: Type Specification of net:getnameinfo()
Type of net:getnameinfo() is specified in the
source file, and the one prevailing in the docs is as below:-
|
-spec
getnameinfo(SockAddr,
Flags)
-> {ok,
Info} | {error,
Reason}
when |
|
|
SockAddr
::
term(), |
|
|
Flags
::
name_info_flags() |
undefined, |
|
|
Info
::
name_info(), |
|
|
Reason
::
term(). |
Currently, the type is SockAddr
::
term(),
and could have been SockAddr
::
socket:sockaddr().
I think fixing it in the source at
L221 should fix it in the documentation as well. But please let me know if it doesn't.
However, I am myself confused about the way the type is specified, so thought I will discuss first before opening a PR.
It is not the net:getnameinfo/1 that I am confused, but about the net:getnameinfo/2. I don't understand the usage of
ifndef and else while specifying this type specification. If you could please point me to a place where I can understand these 2 better. I don't want to make wild guesses here while I am working through the foundations of Erlang.
It could have been simpler had this specification been written like below, even though whatever "ifdef" is doing out there is to be taken into consideration:-
|
SockAddr
::
socket:sockaddr() | term(), |
|
|
Flags
::
name_info_flags() |
undefined, |
|
|
Info
::
name_info(), |
|
|
Reason
::
term() |
Please let me know if there is any misconstrusion on my part.
Thanks and Regards
Nalin Ranjan
|
|
|
Thanks a lot Micael.
I will explore the "ifdef" attribute in that case, for me its a perception as of yet .
1. Does it mean "net" module itself will be gone in future, once "socket" is official?
2. In this particular case of type specification, the only difference is in one of the parameters of the function. I was also wondering if we could have used a union instead to write the same type spec, it would have been simpler? For example, Instead of writing a type spec like this
-ifdef(SOME_PRAGMA_CONDITION) SomeVar :: xxx_type(). -else SomeVar :: yyy_type().
We could specify the same type spec as: SomeVar :: xxx_type() | yyy_type().
Any reason we preferred the former over the latter?
Hi,
It is possible to configure (and build) otp *without* socket (esock) support.
That is what the ifdef'ing is about. Eventually, when socket is properly
official, this will be removed.
Regards,
/BMK
From: erlang-questions <[hidden email]> on behalf of Nalin Ranjan <[hidden email]>
Sent: Tuesday, January 26, 2021 1:12 PM
To: Erlang-Questions Questions <[hidden email]>
Subject: Type Specification of net:getnameinfo()
Type of net:getnameinfo() is specified in the
source file, and the one prevailing in the docs is as below:-
|
-spec
getnameinfo(SockAddr,
Flags)
-> {ok,
Info} | {error,
Reason}
when |
|
|
SockAddr
::
term(), |
|
|
Flags
::
name_info_flags() |
undefined, |
|
|
Info
::
name_info(), |
|
|
Reason
::
term(). |
Currently, the type is SockAddr
::
term(),
and could have been SockAddr
::
socket:sockaddr().
I think fixing it in the source at
L221 should fix it in the documentation as well. But please let me know if it doesn't.
However, I am myself confused about the way the type is specified, so thought I will discuss first before opening a PR.
It is not the net:getnameinfo/1 that I am confused, but about the net:getnameinfo/2. I don't understand the usage of
ifndef and else while specifying this type specification. If you could please point me to a place where I can understand these 2 better. I don't want to make wild guesses here while I am working through the foundations of Erlang.
It could have been simpler had this specification been written like below, even though whatever "ifdef" is doing out there is to be taken into consideration:-
|
SockAddr
::
socket:sockaddr() | term(), |
|
|
Flags
::
name_info_flags() |
undefined, |
|
|
Info
::
name_info(), |
|
|
Reason
::
term() |
Please let me know if there is any misconstrusion on my part.
Thanks and Regards
Nalin Ranjan
|
|
|
On 2021-01-26 21:46, Nalin Ranjan wrote:
> 2. In this particular case of type specification, the only difference is in
> one of the parameters of the function. I was also wondering if we could
> have used a union instead to write the same type spec, it would have been
> simpler?
> For example,
> Instead of writing a type spec like this
>
> -ifdef(SOME_PRAGMA_CONDITION)
> SomeVar :: xxx_type().
> -else
> SomeVar :: yyy_type().
>
> We could specify the same type spec as:
> SomeVar :: xxx_type() | yyy_type().
>
> Any reason we preferred the former over the latter?
If Erlang is compiled without socket support, some types will not exist at
all. Using the preprocessor[1] makes it possible to provide specifications
with types which actually exist, with or without socket support.
[1] https://erlang.org/doc/reference_manual/macros.html--
Nicolas Martyanoff
http://snowsyn.net[hidden email]
|
|
|
Thanks a lot Nicolas.
Will go through, and then may be express my hunch that this is a way in which details are either leaking and/or is not sufficient at the level of a type spec. But who knows I endup correcting myself after a little follow up. नमस्ते।
नलिन रंजन On Tue, Jan 26, 2021, 10:05 PM Nicolas Martyanoff < [hidden email]> wrote: On 2021-01-26 21:46, Nalin Ranjan wrote:
> 2. In this particular case of type specification, the only difference is in
> one of the parameters of the function. I was also wondering if we could
> have used a union instead to write the same type spec, it would have been
> simpler?
> For example,
> Instead of writing a type spec like this
>
> -ifdef(SOME_PRAGMA_CONDITION)
> SomeVar :: xxx_type().
> -else
> SomeVar :: yyy_type().
>
> We could specify the same type spec as:
> SomeVar :: xxx_type() | yyy_type().
>
> Any reason we preferred the former over the latter?
If Erlang is compiled without socket support, some types will not exist at
all. Using the preprocessor[1] makes it possible to provide specifications
with types which actually exist, with or without socket support.
[1] https://erlang.org/doc/reference_manual/macros.html
--
Nicolas Martyanoff
http://snowsyn.net
[hidden email]
|
|
|
For this particular function its a delegation to prim_net:getnameinfo/2 or erlang:error(notsup). Of course, apart from some argument match.
Interesting.
And Micael mentioned its destined to be removed in future. 😑
नमस्ते।
नलिन रंजन
Thanks a lot Nicolas.
Will go through, and then may be express my hunch that this is a way in which details are either leaking and/or is not sufficient at the level of a type spec. But who knows I endup correcting myself after a little follow up. नमस्ते।
नलिन रंजन
On Tue, Jan 26, 2021, 10:05 PM Nicolas Martyanoff < [hidden email]> wrote: On 2021-01-26 21:46, Nalin Ranjan wrote:
> 2. In this particular case of type specification, the only difference is in
> one of the parameters of the function. I was also wondering if we could
> have used a union instead to write the same type spec, it would have been
> simpler?
> For example,
> Instead of writing a type spec like this
>
> -ifdef(SOME_PRAGMA_CONDITION)
> SomeVar :: xxx_type().
> -else
> SomeVar :: yyy_type().
>
> We could specify the same type spec as:
> SomeVar :: xxx_type() | yyy_type().
>
> Any reason we preferred the former over the latter?
If Erlang is compiled without socket support, some types will not exist at
all. Using the preprocessor[1] makes it possible to provide specifications
with types which actually exist, with or without socket support.
[1] https://erlang.org/doc/reference_manual/macros.html
--
Nicolas Martyanoff
http://snowsyn.net
[hidden email]
|
|
|
Hi,
No, net is *not* planned to be removed!
I was talking about the ifdef'ing, nothing else.
Regards,
/BMK
For this particular function its a delegation to prim_net:getnameinfo/2
or erlang:error(notsup). Of course, apart from some argument match.
Interesting.
And Micael mentioned its destined to be removed in future. 😑
नमस्ते।
नलिन रंजन
Thanks a lot Nicolas.
Will go through, and then may be express my hunch that this is a way in which details are either leaking and/or is not sufficient at the level of a type spec. But who knows I endup correcting myself after a little follow up.
नमस्ते।
नलिन रंजन
On Tue, Jan 26, 2021, 10:05 PM Nicolas Martyanoff < [hidden email]> wrote:
On 2021-01-26 21:46, Nalin Ranjan wrote:
> 2. In this particular case of type specification, the only difference is in
> one of the parameters of the function. I was also wondering if we could
> have used a union instead to write the same type spec, it would have been
> simpler?
> For example,
> Instead of writing a type spec like this
>
> -ifdef(SOME_PRAGMA_CONDITION)
> SomeVar :: xxx_type().
> -else
> SomeVar :: yyy_type().
>
> We could specify the same type spec as:
> SomeVar :: xxx_type() | yyy_type().
>
> Any reason we preferred the former over the latter?
If Erlang is compiled without socket support, some types will not exist at
all. Using the preprocessor[1] makes it possible to provide specifications
with types which actually exist, with or without socket support.
[1]
https://erlang.org/doc/reference_manual/macros.html
--
Nicolas Martyanoff
http://snowsyn.net
[hidden email]
|
|
|
Thanks Micael👍, was waiting for it. I will drop my idea for a PR then.
And thanks Nicolas on tip to Preprocessor(Directives). I missed that section. नमस्ते।
नलिन रंजन
Hi,
No, net is *not* planned to be removed!
I was talking about the ifdef'ing, nothing else.
Regards,
/BMK
For this particular function its a delegation to prim_net:getnameinfo/2
or erlang:error(notsup). Of course, apart from some argument match.
Interesting.
And Micael mentioned its destined to be removed in future. 😑
नमस्ते।
नलिन रंजन
Thanks a lot Nicolas.
Will go through, and then may be express my hunch that this is a way in which details are either leaking and/or is not sufficient at the level of a type spec. But who knows I endup correcting myself after a little follow up.
नमस्ते।
नलिन रंजन
On Tue, Jan 26, 2021, 10:05 PM Nicolas Martyanoff < [hidden email]> wrote:
On 2021-01-26 21:46, Nalin Ranjan wrote:
> 2. In this particular case of type specification, the only difference is in
> one of the parameters of the function. I was also wondering if we could
> have used a union instead to write the same type spec, it would have been
> simpler?
> For example,
> Instead of writing a type spec like this
>
> -ifdef(SOME_PRAGMA_CONDITION)
> SomeVar :: xxx_type().
> -else
> SomeVar :: yyy_type().
>
> We could specify the same type spec as:
> SomeVar :: xxx_type() | yyy_type().
>
> Any reason we preferred the former over the latter?
If Erlang is compiled without socket support, some types will not exist at
all. Using the preprocessor[1] makes it possible to provide specifications
with types which actually exist, with or without socket support.
[1]
https://erlang.org/doc/reference_manual/macros.html
--
Nicolas Martyanoff
http://snowsyn.net
[hidden email]
|
|
Locked
