More advocacy for "port-real-fd"
hga@xxxxxx
(07 Sep 2020 15:52 UTC)
|
Re: More advocacy for "port-real-fd"
Shiro Kawai
(07 Sep 2020 20:29 UTC)
|
Re: More advocacy for "port-real-fd"
Lassi Kortela
(10 Sep 2020 16:21 UTC)
|
Re: More advocacy for "port-real-fd" Lassi Kortela (10 Sep 2020 16:29 UTC)
|
Re: More advocacy for "port-real-fd"
Marc Nieper-Wißkirchen
(10 Sep 2020 16:30 UTC)
|
Re: More advocacy for "port-real-fd"
Lassi Kortela
(10 Sep 2020 16:35 UTC)
|
Re: More advocacy for "port-real-fd"
hga@xxxxxx
(10 Sep 2020 16:49 UTC)
|
Re: More advocacy for "port-real-fd" Lassi Kortela 10 Sep 2020 16:29 UTC
IMHO the names `port->fd` and `port-internal-fd` are slightly misleading, though the functionality is good. The name `port->fd` doesn't obviously say that it creates a copy of the fd. RnRS has procedures named like `list-copy` and `string-copy` which create copies of things. Common Lisp has `copy-list`, `copy-seq`, etc. Calling it `file-descriptor-copy` or `copy-file-descriptor` would match these known names. `port-internal-fd` is basically right, but the word `internal` may be superfluous. `port-fd` or `port-file-descriptor` would say as much. Unix users will understand that most ports have an underlying fd. If the intent of `internal` is to say "danger, think twice before using", using a longer name would probably serve the same purpose?