- Is the "large standard library" approach of python and haskell (say)
really problematic wrt. pace of library evolution? Is it wise to
even _have_ an "ext"? If so, what does it mean? Supported and
tested non-mutually-dependent selections from the package ecosystem?
The moral equivalent of boost?
Finally, wrt. naming, in the meeting someone mentioned that:
extern mod "rust-lang.org/ext";
might not really read well. Lots of "ext" in there. Any other names
come to mind?
A name reflecting its true role seems appropriate. Drawing on
the Linux kernel experience, I propose "staging". Alternatively,
"trial", "proposed", "experimental", "unstable". The Boost experience
suggests that explicit interface versioning, if only by naming
convention, would be wise: the most frequently expressed reason
for Boost non-use has been interface instability between releases.
A policy of supporting use of old interfaces in scrupulously
module-name-qualified code, enabling interface evolution
without breaking existing uses, would aid adoption.
As a meta-comment, the reflexive use of abbreviations in
not-frequently-typed names seems like a problem. Surely
modern editors with auto-complete make these unnecessary?
Do we need a policy on what sort of names merit abbreviation,
and how much? (I am forced to admit disappointment at "fn"
instead of "fun".) Alex Stepanov's policy designing STL was
to avoid abbreviations wherever defensible. It mostly worked
out well, although "iterator" turned out to be too long.
Nathan Myers
[email protected]
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
