-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add startsWith and endsWith #127
Comments
I would say I'm not really in favour of it, personally. We're not trying to replicate the JS API here, and it already has That's just my opinion though 🙂 |
To be clear, |
@garyb you do make a good point. I just think that the discoverability of this is low for new people. Should I add an example to the cookbook? |
Sure! That sounds like a good idea. |
I actually ran into this issue a week ago. I ended up using So, I would agree that discoverability is the issue here. |
FWIW I've somewhat often wanted startsWith/endsWith. I would not be opposed to adding them with docs that refer to stripPrefix/stripSuffix. |
I'm not sure what to do here. Should I open a PR here and add |
@mhmdanas I'm just throwing in a point-of-view that startsWith/endsWith are not always functions you don't want. I've written lots of code that checks a prefix to classify something, but still needs to retain the prefix for convenience. I'm not really fighting for their inclusion, other than saying that it's expected functionality, and I think it's fine if we did include them while also suggesting that stripPrefix/stripSuffix may be more appropriate. |
What about performance, is it not a consideration? I mean if this is a standard functions of String in JS. |
Stripping a string prefix is cheap (i.e. O(1)) in JS because JS strings are immutable. We should avoid unnecessary FFI here because that creates problems for alternative backends. |
We can't be sure that is the case on other backends (it might as well be for at least most; I'm not sure).
I don't think it should be much of a problem because it's just two extra functions, but yeah, it's still two more functions to implement in the FFI. |
I think a backend which uses a mutable type for Strings is probably incorrect; if you want to write a PureScript backend for a language which does not provide an immutable String type, then you should probably map PureScript strings to some other type in your backend which is an immutable string. We should really write a spec for what is expected of a backend, and specifically how the primitive types work. There are also problems around the encoding of a String as well (whether invalid UTF-16 is allowed, for instance). |
These functions are already present in
purescript-stringutils
but many people, especially ones coming from JavaScript, expect them to be present in the main strings library.Should I make a PR to fix this?
The text was updated successfully, but these errors were encountered: