Refactor Scalar Operations

[AlexandruGG]

This PR refactors Collection Operations which currently return a single scalar value inside a collection, returning the scalar directly.

• Contains
• Every
• Falsy
• Has
• Match + static analysis check & type fixes
• Nullsy
• Truthy

Related to #107.

[AlexandruGG]

I'm gonna give this one a final look a bit later before marking it ready for review

[drupol]

I'm gonna give this one a final look a bit later before marking it ready for review

Take your time mate, there is no hurry.

Do you think it would be possible to add some documentation that explains

• All the methods of the Collection returns a new collection
• Only the methods X,Y,Z returns something different
• Explaining the reasons of this breaking change.

I will also use that part in the changelog when doing the release later on.

[AlexandruGG]

I'm gonna give this one a final look a bit later before marking it ready for review

Take your time mate, there is no hurry.

Do you think it would be possible to add some documentation that explains

• All the methods of the Collection returns a new collection
• Only the methods X,Y,Z returns something different
• Explaining the reasons of this breaking change.

I will also use that part in the changelog when doing the release later on.

Yeah for sure! I was thinking to add a part in the documentation to explain about the operations but I forgot about it there for a moment 😄.

Regarding the last bullet point do you want that to be in the documentation or do you mean in the PR description?

[drupol]

Ok good 👍

I think we can do it in the documentation and I'll copy paste it for the changelog later.

[AlexandruGG]

Ok good 👍

I think we can do it in the documentation and I'll copy paste it for the changelog later.

Sounds good. Btw for BC breaking changes like this should we have a new major version? I.e 5.0?

[drupol]

I don't know yet. We will see when it's done.

[AlexandruGG]

did a new count and this is up over 100 now 🎉

[drupol]

Excellent :-)

[AlexandruGG]

I don't know yet. We will see when it's done.

I think it depends if we want this project to follow semver or not. Because based on that any backwards-incompatible API changes should be done as part of a new major version.

Also if we do up the version when releasing this we should up the docs version as well.

[AlexandruGG]

@drupol let me know what you think about the documentation update

[drupol]

I think the explanation is overall really great and I wouldn't change a thing, except for the classification points here.

What I propose is to list the operation types as such:

1. Operations which returns a boolean: contains, every, falsy, has... etc etc
2. Operations which returns a Collection of Collection: span, partition
3. Operation which returns an array: all
4. Operation which returns a Collection: all the rest.

(be carefull Collection::key() might return anything, not only a scalar, but anything)

Also, what do you think about:

• Updating the signatures of all the operations in the API page and add their return type ?
  or
• Updating all operations and add a note about the return type ?

(about that page, it's very sad we cannot generate the documentation automatically from the classes themselves!)

Let me know what you think.

[AlexandruGG]

@drupol thank you for the feedback, I've done some changes to the numbered list to incorporate your suggestions, with a couple tweaks. Let me know what you think of this new classification :).

Regarding updating the signatures of the operations in the docs -> it's something that I thought about today as well 😄 . I'll do it in a future PR for all of them

[drupol]

Thanks all good now :)

[AlexandruGG]

@drupol great, this is all ready on my side 😁

[drupol]

I don't know yet. We will see when it's done.

I think it depends if we want this project to follow semver or not. Because based on that any backwards-incompatible API changes should be done as part of a new major version.

Also if we do up the version when releasing this we should up the docs version as well.

We should definitely follow semver... and therefore it's going to be version 5 indeed.

[AlexandruGG]

I don't know yet. We will see when it's done.

I think it depends if we want this project to follow semver or not. Because based on that any backwards-incompatible API changes should be done as part of a new major version.
Also if we do up the version when releasing this we should up the docs version as well.

We should definitely follow semver... and therefore it's going to be version 5 indeed.

Cool in that case I think we can do the map change as well to remove the deprecation and only allow one callback, I'll do it in a future PR.

[drupol]

Thanks, a big one done 🥇