Closed charliethomson closed 4 years ago
@charliethomson I seem to recall one of the light guiding principles we had when we started working on this was to do a faithful port of all the Python logic, warts and all, and get it working and passing tests before we changed things around to make it more idiomatic.
I don't know if that's something we still want to hold on to, but I seem to recall us thinking the original code was hard enough to grok as-is without also having to translate the idioms.
The interface would mirror the Python version better and be more idiomatic if we implemented these changes.
Here's the original source for the two functions:
def skip_char(self, amt=1):
self.s = self.s[amt:]
def str_at(self, idx):
return self.s[idx : idx + 1]
skip_char
modifies (&mut self
) self.s
to skip forward by amt
(currently Option<usize>
, proposing usize
) characters
str_at
takes what in rust would be a &self
and an index (usize
) and returns the character (Option<char>
) at the index
When compared to the original source, I think the proposed change not only makes the interface cleaner, but it makes it mirror the python better
Yes, if we want to mirror the original API, it should be done that way. I was thinking of this but feels weird it is implemented the current way instead of being similar to python.
I think we should make
str_at
a method instead of an associated function, as well as, forstr_at
andskip_char
, stop taking a &str argument and just modifyself.s
within the function. I also think we should stop taking anOption<usize>
onskip_char
and just take ausize
(from what I can gather, theOption
is only used because the python uses a default arg and it wants to mirror that, however I feel that its clearer to just take a number)Problem
Current interface
Proposed change
after
Thoughts? There may be a reason it's designed like that but it makes using the interface verbose, tedious, and ugly.