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

Update Documentation III #88

Merged
merged 10 commits into from
May 20, 2021
Merged

Update Documentation III #88

merged 10 commits into from
May 20, 2021

Conversation

AlexandruGG
Copy link
Collaborator

@AlexandruGG AlexandruGG commented May 20, 2021

This PR updates more items in the documentation

  • Update Usage page
  • Update README
  • Add missing methods from API docs

Follows #86.

@AlexandruGG
Copy link
Collaborator Author

AlexandruGG commented May 20, 2021

@drupol There are methods in the Collection implementation that are not included in the Collection Interface, and are not mentioned as methods in the documentation either. A few examples I noticed: count(), current().

Before I added them I wanted to check with you:

  1. should they be in the contract? (with their own interface like Countable)
  2. should they be in the API docs methods section?

Lastly, a related question: when the library is used in another project, should the interface or the implementation be used in function and method arguments and return types? My instinct says the interface but then the two should be kept in sync otherwise it can result in issues.

Copy link
Collaborator

@drupol drupol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added minor changes.

docs/pages/code/simple.php Outdated Show resolved Hide resolved
docs/pages/code/simple.php Outdated Show resolved Hide resolved
docs/pages/code/simple.php Outdated Show resolved Hide resolved
docs/pages/code/simple.php Outdated Show resolved Hide resolved
@drupol
Copy link
Collaborator

drupol commented May 20, 2021

@drupol There are methods in the Collection implementation that are not included in the Collection Interface, and are not mentioned as methods in the documentation either. A few examples I noticed: count(), current().

Indeed, those are missing and we should fix that.

Before I added them I wanted to check with you:

1. should they be in the contract? (with their own interface like Countable)

Countable is already there, but current I don't know, I'm still unsure.
I think we should add it for sure, but at the same time, it's not returning a collection so, I'm unsure.
What's your opinion on this?

2. should they be in the API docs methods section?

Definitely, without hesitation.

Lastly, a related question: when the library is used in another project, should the interface or the implementation be used in function and method arguments and return types? My instinct says the interface but then the two should be kept in sync otherwise it can result in issues.

I see, this is linked to your previous questions.

I always try to rely on the interface all the time and yes, it would make sense to sync everything.

@AlexandruGG
Copy link
Collaborator Author

@drupol There are methods in the Collection implementation that are not included in the Collection Interface, and are not mentioned as methods in the documentation either. A few examples I noticed: count(), current().

Indeed, those are missing and we should fix that.

Before I added them I wanted to check with you:

1. should they be in the contract? (with their own interface like Countable)

Countable is already there, but current I don't know, I'm still unsure.
I think we should add it for sure, but at the same time, it's not returning a collection so, I'm unsure.
What's your opinion on this?

2. should they be in the API docs methods section?

Definitely, without hesitation.

Lastly, a related question: when the library is used in another project, should the interface or the implementation be used in function and method arguments and return types? My instinct says the interface but then the two should be kept in sync otherwise it can result in issues.

I see, this is linked to your previous questions.

I always try to rely on the interface all the time and yes, it would make sense to sync everything.

Thanks for the quick reply on this. I think I was blind when I said things are not in the interface 😄 . They are there actually, just some things missing from the documentation, which I will add.

@@ -57,5 +57,5 @@
* "(4, b)"
* "(3, c)"
* "(4, d)"
* "(5, e)"
* "(5, e)".
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahaha we can disable that rule if it's really a problem :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nah it's fine I think it's useful for php docs in general 😄

Comment on lines +1447 to +1486
pipe
~~~~

Pipe together multiple operations and apply them in succession to the collection items.
To maintain a lazy nature, each operation needs to return a ``Generator``.
Custom operations and operations provided in the API can be combined together.

Interface: `Pipeable`_

Signature: ``Collection::pipe(callable ...$callables);``

.. code-block:: php

$square = static function ($collection): Generator {
foreach ($collection as $item) {
yield $item ** 2;
}
};

$toString = static function ($collection): Generator {
foreach ($collection as $item) {
yield (string) $item;
}
};

$times = new class() extends AbstractOperation {
public function __invoke(): Closure
{
return static function ($collection): Generator {
foreach ($collection as $item) {
yield "{$item}x";
}
};
}
};

Collection::fromIterable(range(1, 5))
->pipe($square, Reverse::of(), $toString, $times())
->all(); // ['25x', '16x', '9x', '4x', '1x']

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope this is a good definition and showcase of pipe. Let me know if you think anything else should be included in the description.

Another thing I noticed: it's return type is self vs CollectionInterface like most other methods: https://github.com/loophp/collection/blob/master/src/Collection.php#L610. Is that just an error or was there a reason for it?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something that I should sort one day. Returning self or the interface. I haven't found a proper way to do it yet.

Regarding the explanation, it's perfect :)

@AlexandruGG AlexandruGG marked this pull request as ready for review May 20, 2021 17:33
@drupol drupol merged commit aae58e8 into loophp:master May 20, 2021
@drupol
Copy link
Collaborator

drupol commented May 20, 2021

Thanks for your time and dedication, I'm glad and grateful to receive such pull requests!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants