Skip to content
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 Extension methods to strings and others #578

Open
feinstein opened this issue Dec 20, 2019 · 7 comments
Open

Add Extension methods to strings and others #578

feinstein opened this issue Dec 20, 2019 · 7 comments

Comments

@feinstein
Copy link
Contributor

feinstein commented Dec 20, 2019

It would be nice to convert methos such as isBlank("myString") to "myString".isBlank, using the new Extension methods from Dart 2.7.

@feinstein
Copy link
Contributor Author

@cbracken I am willing to add the extensions, but extensions are only supported on Dart 2.6 and this will break quiver's compatibility with older project.

Thoughts?

@fabiancrx
Copy link

I would like having them as extension methods. I think auto completion and commodity will be enhanced.

@cbracken
Copy link
Member

Sorry it took a while to notice this -- agreed, I think this would be a nice feature.

Quiver is currently backward compatible to Dart SDK 2.0.0-dev.61 so this would be considered a breaking change and we'd need to bump our major version to 3.0.0. Given that non-null by default is also on its way, what I might do is create a 3.0.0-dev branch that we can commit things like this to and publish dev releases from to pub. Seem reasonable?

@cbracken
Copy link
Member

/cc @jtmcdole @yjbanov for thoughts on the branch strategy. This is pretty much the approach we took with Dart 2.0 and I feel like that worked about as well as could be expected given the extent of those changes (which reminds me... there are still some method stubs we haven't finished implementing).

@feinstein
Copy link
Contributor Author

feinstein commented Sep 18, 2020

@cbracken I like it. Let me know when it's done so I can add the extensions.

@cbracken
Copy link
Member

Branch 3.0.0-dev has now been created.

@feinstein
Copy link
Contributor Author

@cbracken I am almost done, I just want to confirm with you how do you prefer the tests to be structured.

I am placing them all together under strings_test.dart, so if someone changes one test doesn't forget to update another file as well.

But I am not sure how to expand the tests.

For example, here's one test:

test('should consider empty string a blank', () {
  expect(isBlank(''), isTrue);
});

I can convert this to:

1:

test('should consider empty string a blank', () {
  String s = '';
  expect(isBlank(s), isTrue);
  expect(s.isBlank, isTrue);
});

or

2:

test('should consider empty string a blank', () {
  expect(isBlank(''), isTrue);
  expect(''.isBlank, isTrue);
});

2 is easier to do and I also find 2 easier to read, but 1 is more maintainable, as we can change the string once and all the tests will reflect it.

Do you have any particular preference? I started the file as 1 already, but on loop tests I am finding it a bit uglier.

feinstein added a commit to feinstein/quiver-dart that referenced this issue Sep 23, 2020
feinstein added a commit to feinstein/quiver-dart that referenced this issue Sep 23, 2020
cbracken pushed a commit to cbracken/quiver-dart that referenced this issue Apr 9, 2021
cbracken pushed a commit to cbracken/quiver-dart that referenced this issue Apr 9, 2021
feinstein added a commit to feinstein/quiver-dart that referenced this issue Apr 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants