Type Specification of net:getnameinfo()

Nalin Ranjan ranjanified@REDACTED
Wed Jan 27 15:39:37 CET 2021


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 <micael.karlberg@REDACTED>
wrote:

> Hi,
>
> No, net is *not* planned to be removed!
> I was talking about the ifdef'ing, nothing else.
>
> Regards,
>      /BMK
>
> ------------------------------
> *From:* Nalin Ranjan <ranjanified@REDACTED>
> *Sent:* Wednesday, January 27, 2021 3:01 PM
> *To:* Nicolas Martyanoff <khaelin@REDACTED>
> *Cc:* Micael Karlberg <micael.karlberg@REDACTED>; Erlang-Questions
> Questions <erlang-questions@REDACTED>
> *Subject:* Re: Type Specification of net:getnameinfo()
>
> For this particular function its a delegation to prim_net:getnameinfo/2
> <https://protect2.fireeye.com/v1/url?k=84aecd19-db35f434-84ae8d82-8692dc8284cb-c2634a3f89b46f21&q=1&e=b2b6d2f6-9676-43a2-901a-9a8708bb6c75&u=https%3A%2F%2Fgithub.com%2Ferlang%2Fotp%2Fblob%2Fmaster%2Ferts%2Fpreloaded%2Fsrc%2Fprim_net.erl%23L160>
> 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 <ranjanified@REDACTED>
> 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 <khaelin@REDACTED>
> 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
> <https://protect2.fireeye.com/v1/url?k=7959406e-26c27943-795900f5-8692dc8284cb-69c47e0211b63af4&q=1&e=b2b6d2f6-9676-43a2-901a-9a8708bb6c75&u=https%3A%2F%2Ferlang.org%2Fdoc%2Freference_manual%2Fmacros.html>
>
> --
> Nicolas Martyanoff
> http://snowsyn.net
> <https://protect2.fireeye.com/v1/url?k=602bedc6-3fb0d4eb-602bad5d-8692dc8284cb-93ab7630f8bbef4e&q=1&e=b2b6d2f6-9676-43a2-901a-9a8708bb6c75&u=http%3A%2F%2Fsnowsyn.net%2F>
> khaelin@REDACTED
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210127/a58c89d1/attachment.htm>


More information about the erlang-questions mailing list