> 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
