Oh and while we're belligerently bikeshedding, we should rename `to_str` to `to_string` once we rename `StrBuf` to `String`. :)
On Wed, May 28, 2014 at 9:00 PM, Benjamin Striegel <ben.strie...@gmail.com>wrote: > > but people will still end up calling the > > *exact same method* > ...Except when they actually intended to call any other method of > determining the length of a string, but were stymied by poor naming and > inadequate understanding. But if your argument is "people will only call > the method that tells them how many bytes are in the string when they want > to know how many bytes are in the string", then yes, I should hope so. > Let's help them understand which method is appropriate. > > To reiterate, it simply doesn't make sense to ask what the length of a > string is. You may as well ask what color the string is, or where the > string went to high school, or how many times the string rode the roller > coaster that one year on the first day of summer vacation when the string's > parents took the string to that amusement park and the weather said that it > was going to rain so there were almost no crowds that day but then it > didn't rain and all the rides were open with absolutely no lines whatsoever. > > As Daniel has mentioned above, if you want to perform byte operations on a > String without being forced to type "byte" every time, then call > .as_bytes() on it once and run wild. Though at this point I think at this > we're just arguing in circles, and will have to simply agree to disagree. > > > On Wed, May 28, 2014 at 7:00 PM, Kevin Ballard <ke...@sb.org> wrote: > >> On May 28, 2014, at 3:24 PM, Huon Wilson <dbau...@gmail.com> wrote: >> >> Changing the names of methods on strings seems very similar how Path does >> not implement Show (except with even stronger motivation, because strings >> have at least 3 sensible interpretations of what the length could be). >> >> >> I disagree completely. >> >> Path does not implement Show, because of ToStr (and just generally, >> because Show can be used to convert to a string representation). This isn't >> a problem for most types, but paths are special in that a lot of people >> think that they can be represented with strings, and therefore will try to >> do that. Because Path does not implement Show it's difficult to incorrectly >> convert it to a string (it exposes methods for getting an Option<&str> >> which is the correct way to do it). >> >> This is about preventing the user from doing something incorrectly, and >> forcing them to use the correct method. >> >> Meanwhile, renaming .len() to .byte_len() doesn't actually prevent >> anything. It will just confuse people (and cause a lot of unnecessary >> typing of "byte_"), but people will still end up calling the *exact same >> method*. They did the same operation, they just got annoyed in the >> process. >> >> It's important to note here that in most cases .len() actually is the >> correct method to call. This has been discussed before, but basically, >> string manipulation needs to use byte indexes (well, code unit indexes) to >> be at all efficient, and that's why the character-based methods have >> special names. This means that the byte-based methods are the ones we're >> expecting people to use. Renaming them doesn't change that fact. >> >> If someone doesn't give any thought to non-ASCII text, putting "byte" in >> the method name isn't going to change that. And if they do give thought to >> non-ASCII text, leaving "byte" out of the name doesn't cause any issues. >> >> Don't forget that renaming .byte_len() only makes sense if we rename >> .slice()/.slice_from()/.slice_to() to >> .byte_slice()/.byte_slice_from()/.byte_slice_to(). And besides being >> extremely verbose, these methods imply that they return a "byte slice", or >> a &[u8]. >> >> -Kevin >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
