5 ms·

A Cross-Platform String Library Written in Swift

32 points by febin 10y ago

aphextron 10y ago
How on Earth is this 'cross-platform'?
- Someone 10y ago
  Or a string library? It is a library of functions that manipulate objects of the language built-in String type, not a library that implements a string type from scratch.
  - coldtea 10y ago
    That's still a string library. string.h doesn't implement any "string type" from scratch either.
- orbitur 10y ago
  How is it not? It doesn't rely on any Apple-specific APIs.
- coldtea 10y ago
  Swift is cross-platform (and open source), and obviously this doesn't depend on parts of Swift (like the iOS/OS X only APIs) that are not available on other platforms, but only on the core (and portable) libs.
Negative1 10y ago
Two things I'm not a fan of so far in the API design. 1) Function names are misleading or not descriptive enough. E.g. isAlpha(). I assumed this meant is alphanumeric, but it actually means isAlphabetic (as in no numeric values at all). isAlphanumeric() clears this up, but just call the first isAlphabetic and remove any ambiguity. 2) Explicit binary inverts; e.g. isUppercased(), isLowercased(). This leads to bad coding style as conditionals that point in the affirmative usually leads to easier to read code. If it's not uppercased of course its lowercased, so why keep a function around to point this out? Save on the cognitive load on the users and just keep one around. Let them negate it for the desired result. Otherwise, thank you for contributing what looks to be a pretty handy library that isn't tied to just MacOS/iOS and Xcode. I'm really starting to enjoy Swift and am curious to use it in non-client environments soon and a library like this is a pretty nice tool to have.
- TazeTSchnitzel 10y ago
  > 1) Function names are misleading or not descriptive enough. E.g. isAlpha(). I assumed this meant is alphanumeric, but it actually means isAlphabetic Why should it mean alphanumeric? C's isalpha() also tests for being a letter, for instance, and has isalnum() for alphanumericness. > If it's not uppercased of course its lowercased If you're working exclusively with ASCII and ignoring non-letter characters, yes. But is this library bound by those constraints?
  - setr 10y ago
    what non-letter character should succeed in both isLowercase and isUppercase?
    - TazeTSchnitzel 10y ago
      None. But letters can be neither lowercase nor uppercase.
      - setr 10y ago
        In which case, the function(s) should really be throwing some kind of error, since they can't reasonably be applied to the input. But checking !(isUppercase(str) || isLowercase(str)) to see if its not case-able(?) is absurd Obviously you'd instead want the function notCaseable(str).
mgottein 10y ago
Strings are one of the most difficult things to get right in any standard library. You can be like C and offer barebones support, but many developers will make mistakes. You can be like Java and offer much more complete support, but you can never quite satisfy everyone's use case and people complain. I personally would never have even thought to include functions like `kebabCased`, this is a very interesting take on a string library. Overall, good stuff.
RazerM 10y ago
Why is @discardableResult used here? https://github.com/ArtSabintsev/Guitar/blob/0dc71e9dea5ba97592f2481385662b2ab5aad19e/Sources/Guitar.swift#L77 https://github.com/ArtSabintsev/Guitar/blob/0dc71e9dea5ba975...

32 points by febin 10y ago

aphextron 10y ago

How on Earth is this 'cross-platform'?

Someone 10y ago
Or a string library? It is a library of functions that manipulate objects of the language built-in String type, not a library that implements a string type from scratch.
- coldtea 10y ago
  That's still a string library. string.h doesn't implement any "string type" from scratch either.
orbitur 10y ago
How is it not? It doesn't rely on any Apple-specific APIs.
coldtea 10y ago
Swift is cross-platform (and open source), and obviously this doesn't depend on parts of Swift (like the iOS/OS X only APIs) that are not available on other platforms, but only on the core (and portable) libs.

Negative1 10y ago

Two things I'm not a fan of so far in the API design. 1) Function names are misleading or not descriptive enough. E.g. isAlpha(). I assumed this meant is alphanumeric, but it actually means isAlphabetic (as in no numeric values at all). isAlphanumeric() clears this up, but just call the first isAlphabetic and remove any ambiguity. 2) Explicit binary inverts; e.g. isUppercased(), isLowercased(). This leads to bad coding style as conditionals that point in the affirmative usually leads to easier to read code. If it's not uppercased of course its lowercased, so why keep a function around to point this out? Save on the cognitive load on the users and just keep one around. Let them negate it for the desired result. Otherwise, thank you for contributing what looks to be a pretty handy library that isn't tied to just MacOS/iOS and Xcode. I'm really starting to enjoy Swift and am curious to use it in non-client environments soon and a library like this is a pretty nice tool to have.

TazeTSchnitzel 10y ago
> 1) Function names are misleading or not descriptive enough. E.g. isAlpha(). I assumed this meant is alphanumeric, but it actually means isAlphabetic Why should it mean alphanumeric? C's isalpha() also tests for being a letter, for instance, and has isalnum() for alphanumericness. > If it's not uppercased of course its lowercased If you're working exclusively with ASCII and ignoring non-letter characters, yes. But is this library bound by those constraints?
- setr 10y ago
  what non-letter character should succeed in both isLowercase and isUppercase?
  - TazeTSchnitzel 10y ago
    None. But letters can be neither lowercase nor uppercase.
    - setr 10y ago
      In which case, the function(s) should really be throwing some kind of error, since they can't reasonably be applied to the input. But checking !(isUppercase(str) || isLowercase(str)) to see if its not case-able(?) is absurd Obviously you'd instead want the function notCaseable(str).

mgottein 10y ago

Strings are one of the most difficult things to get right in any standard library. You can be like C and offer barebones support, but many developers will make mistakes. You can be like Java and offer much more complete support, but you can never quite satisfy everyone's use case and people complain. I personally would never have even thought to include functions like `kebabCased`, this is a very interesting take on a string library. Overall, good stuff.

RazerM 10y ago

Why is @discardableResult used here? https://github.com/ArtSabintsev/Guitar/blob/0dc71e9dea5ba97592f2481385662b2ab5aad19e/Sources/Guitar.swift#L77 https://github.com/ArtSabintsev/Guitar/blob/0dc71e9dea5ba975...