esentis / string_extensions Goto Github PK

suggestion

A method that detects and replaces common symbol uses as letters. E.g. the word stef@n1a could be "translated" to stefania.

suggestion

I think a method that removes symbols would be quite useful. For instance, if a user writes something like "Μαρία@ t!1he 3$rd!!!!" for example, you get "Μαρία the 3rd".

quiestion

A method called .onlyLetters() seems to depreciate since v0.2.3, and is renamed to onlyLatin, is that correct?

suggestion

Wouldn't it be nice to add a method that combines onlyLatin and onlyGreek named onlyLetters?

extension InsertAt on String {
String insertAt(int i, String value) {
final start = substring(0, i);
final end = substring(i);
return start + value + end;
}
}

Not so much a feature request, more a design question to satisfy my curiosity. If something can be done about it, all the better!

This code gives an error that "A value of type 'String?' can't be assigned to a variable of type 'String'". IMHO this should be the ideal way to use the extension properties.

String foo = "foo".capitalize;

Instead we are forced to use a ! if we know the initial string to not be null.

String foo = "foo".capitalize!;

I understand that the advantage of the current approach is so we can easily work with nullable strings like this.

String? bar = maybe ? "not-null" : null;
String? biz = bar.capitalize;

However it seems more appropriate to force the usage of the ? operator where things might be null instead of forcing the ! operator where we know they aren't null, like so.

String foo = "foo".capitalize; // Should be good
String? biz = bar?.capitalize; // Should be good. Forcing ? is appropriate since bar may be null

String foo = "foo".capitalize!; // Should be bad. "foo" is known to not be null, so .capitalize should be the same
String? biz = bar.capitalize; // Should be bad. bar may be null so it shouldn't have a .capitalize property. use ?.capitalize instead

I know changing it would break backwards compatibility, so I'm not requesting it be changed, but if I'm missing something and the current approach was chosen for some other benefit I'm not aware of, I'd love to learn what that is (I'm kind of new to dart and exploring its mechanisms). Maybe there can be two extension classes, one on String and the other on String? to keep backwards compatibility? (The latter could easily be implemented in terms of the former, though importing both may cause name collisions)