On 13-04-23 11:00 AM, Nathan Myers wrote:
> 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.
It's not for experimental stuff. Let me clarify the role we're
discussing. The "ext" library, for lack of a better name, will:
- Be a library hosted in a mozilla and/or rust-lang.org repo
- That _just re-exports_ (pub extern mod's) a bunch of packages
- Each of which is:
- Developed independently in their own repos
- By their own contributor communities
- At their own pace
- Applying some editorial standards to the selected packages
- And supporting them version-to-version even if they bitrot
or radically change upstream
> As a meta-comment, the reflexive use of abbreviations in
> not-frequently-typed names seems like a problem.
I don't find it a problem. A bunch of people have expressed distaste,
but a bunch of others have expressed pleasure. As a recently-tweeted
quip put it, "One person's idiom is another's boilerplate."
> modern editors with auto-complete make these unnecessary?
We've generally avoided (and I am opposed to) design choices that
require a "modern editor". At least anything more modern than vi or
emacs. I know some people even write code in acme, or microemacs.
> Do we need a policy on what sort of names merit abbreviation,
> and how much?
For keywords, it's "5 chars or less", where 5 is defined as 6 for cases
that you don't have to write very often (extern, static, struct,
unsafe), and 3 when you have to write it a lot (use, let, for). We could
have used "fun" rather than "fn" but I figure the sml lambda form and
the rc shell are both pretty much unassailable good taste, so I'm happy
with "fn".
For other names there's not much of a guideline. "Eschew obfuscation"?
> 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.
Where a name in STL is short and pithy, I'm not averse to following
suit. I would consider these STL names fine:
begin end set reset clear size flip test assign insert erase
swap clear front back push pop top
and these STL names perhaps "a little overwrought":
iterator const_iterator reverse_iterator reference value_type
pointer difference_type allocator shared_ptr unique_ptr
static_cast unordered_map uniform_int_distribution
lexicographical_compare set_symmetric_difference
But when there's nothing appropriate and short, long sometimes has to
do. I guess we can't always pick nice 1-2 syllable names.
There was some work on this sort of guideline-making in the style guide
recently, but I recall you objecting to those guidelines (indeed, the
mere idea of them). And you also suggested we sacrifice everything for
"conscious attention, screen space, editing time, short-term memory",
which suggests (to me) a strong preference for short names. So I can't
really tell what if anything you feel like we should be doing differently.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
