Type Specification of net:getnameinfo()

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Type Specification of net:getnameinfo()

Nalin Ranjan
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



Reply | Threaded
Open this post in threaded view
|

Re: Type Specification of net:getnameinfo()

Micael Karlberg-5
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



Reply | Threaded
Open this post in threaded view
|

Re: Type Specification of net:getnameinfo()

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?


नमस्ते।
नलिन रंजन

On Tue, Jan 26, 2021, 8:25 PM Micael Karlberg <[hidden email]> wrote:
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



Reply | Threaded
Open this post in threaded view
|

Re: Type Specification of net:getnameinfo()

Nicolas Martyanoff
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]
Reply | Threaded
Open this post in threaded view
|

Re: Type Specification of net:getnameinfo()

Nalin Ranjan
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]
Reply | Threaded
Open this post in threaded view
|

Re: Type Specification of net:getnameinfo()

Nalin Ranjan
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. 😑

नमस्ते।
नलिन रंजन

On Wed, Jan 27, 2021 at 9:13 AM Nalin Ranjan <[hidden email]> wrote:
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]
Reply | Threaded
Open this post in threaded view
|

Re: Type Specification of net:getnameinfo()

Micael Karlberg-5
Hi,

No, net is *not* planned to be removed!
I was talking about the ifdef'ing, nothing else.

Regards,
     /BMK


From: Nalin Ranjan <[hidden email]>
Sent: Wednesday, January 27, 2021 3:01 PM
To: Nicolas Martyanoff <[hidden email]>
Cc: Micael Karlberg <[hidden email]>; Erlang-Questions Questions <[hidden email]>
Subject: Re: Type Specification of net:getnameinfo()
 
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. 😑

नमस्ते।
नलिन रंजन

On Wed, Jan 27, 2021 at 9:13 AM Nalin Ranjan <[hidden email]> wrote:
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]
Reply | Threaded
Open this post in threaded view
|

Re: Type Specification of net:getnameinfo()

Nalin Ranjan
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.

नमस्ते।
नलिन रंजन

On Wed, Jan 27, 2021, 8:03 PM Micael Karlberg <[hidden email]> wrote:
Hi,

No, net is *not* planned to be removed!
I was talking about the ifdef'ing, nothing else.

Regards,
     /BMK


From: Nalin Ranjan <[hidden email]>
Sent: Wednesday, January 27, 2021 3:01 PM
To: Nicolas Martyanoff <[hidden email]>
Cc: Micael Karlberg <[hidden email]>; Erlang-Questions Questions <[hidden email]>
Subject: Re: Type Specification of net:getnameinfo()
 
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. 😑

नमस्ते।
नलिन रंजन

On Wed, Jan 27, 2021 at 9:13 AM Nalin Ranjan <[hidden email]> wrote:
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]