Is there a plan to migrate to dart null safety?

[springeye]

[jcmellado]

Some work was done here: https://github.com/jcmellado/dartis/issues/34

I tried using the automated tools provided by Google, but resulting code still need some major refactoring.

[isoos]

I tried using the automated tools provided by Google, but resulting code still need some major refactoring.

I've briefly looked at the code, and I think the most difficult part is where you decide which codec to use based on the runtime type, but then nullable and non-nullable types do get washed up. If that part is refactored, then the rest will be easier to migrate.

[Silentdoer]

hi, this has any updates?

[jcmellado]

No, there are some open pull requests, but they still need a bit of love

[jodinathan]

what does it need to solve in the PR so we can have null safety?

[isoos]

Note: if you need only key-value cache and nothing more, we ended up re-implementing the protocol bits in package:neat_cache.

[jodinathan]

Note: if you need only key-value cache and nothing more, we ended up re-implementing the protocol bits in package:neat_cache.

we need INCR and other Redis commands. But thanks for the link, seems a nice and simple KV package

[jcmellado]

There are still some conflicts there: https://github.com/jcmellado/dartis/pull/41

[jodinathan]

fixed the conflicts here https://github.com/jcmellado/dartis/pull/44/

[jodinathan]

@jcmellado do we need any changes to merge the PR?

[jcmellado]

No, thanks

[kevinelliott]

Looks like there's been some additions here for null safety. How far are we from a release that incorporates?

[jcmellado]

I tried the different provided solution (thanks all for the effort), but none of them worked properly.

To detect the correct types at runtime is the hard part.

[DaleBeckles]

@jcmellado I appreciate all your efforts on the original package and ongoing migration to null safety. What are your thoughts/plans on completing the migration to null safety?

[jodinathan]

I tried the different provided solution (thanks all for the effort), but none of them worked properly.

To detect the correct types at runtime is the hard part.

would you please clarify what needs to be done maybe we can help =]

[jcmellado]

Ok, I'll try to explain it.

• The code is in the develop branch.
• All the classes in the commands folder must be modified. All the methods must return a nullable type. For example: Future<int> must be replaced with Future<int?>.
• I already modified the cluster, connection, geo, hash and hyperloglog commands. But it's still work in progress. I started to modify them just for testing the library. I wouldn't modify any commands more until the tests pass for those commands.
• If you run the tests then you will get the "Unexpected value of type "ArrayReply" error for the modified commands.
• The problem is caused by the classes in the protocol/codec.dart file. The code doesn't work with the new nullable type system. It's necessary to redesign that part.

[DaleBeckles]

@jodinathan are you intending to work on dartis migration to null safety? Perhaps I could assist. Please advise.

[Silentdoer]

dedis may be a alternative