Skip to content

#13 - Moving order-rely methods to Linear interface#23

Merged
maciej-sz merged 2 commits intomainfrom
feat/#13/move-ordered-methods
Mar 16, 2025
Merged

#13 - Moving order-rely methods to Linear interface#23
maciej-sz merged 2 commits intomainfrom
feat/#13/move-ordered-methods

Conversation

@maciej-sz
Copy link
Copy Markdown
Contributor

@maciej-sz maciej-sz commented Mar 16, 2025

Summary by CodeRabbit

  • New Features

    • Enhanced collection APIs now offer additional operations including element lookup, counting, iteration (both forward and reverse), aggregation, and conversion functions.
  • Bug Fixes

    • Removed outdated test cases, streamlining the testing framework for collections.
  • Refactor

    • Reorganized collection interfaces to clearly separate standard operations from reverse-specific functionalities for improved clarity.
  • Tests

    • Expanded test coverage to ensure reliable behavior for the newly introduced collection capabilities.

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Mar 16, 2025

Walkthrough

This pull request removes several legacy test functions and their case generators for reverse collection operations, while simultaneously restructuring interface definitions. The Base interface now receives added functional methods and all reverse methods are migrated to the Linear interface. Additionally, the signature of the comfyFindLast function has been updated to require collections that implement Linear[V]. Moreover, new tests for linear collections, including reverse and search operations, have been added and existing tests have been updated to use the new type parameter.

Changes

File(s) Change Summary
base_cases_test.go Removed functions generating/executing test cases for reverse operations, including methods: EachRev, EachRevUntil, FindLast, FoldRev, ReduceRev, SearchRev and their pair variants.
definitions.go Updated interfaces: added methods (Contains, Count, Each, EachUntil, Fold, IsEmpty, Len, Search, Reduce, ToSlice, Values) to Base and moved reverse methods (EachRev, EachRevUntil, FindLast, FoldRev, ReduceRev, SearchRev) exclusively to Linear.
functions_internal.go Changed the signature of comfyFindLast from requiring Base[V] to requiring Linear[V].
linear_cases_test.go Added new test types and functions (getEachRevCases, getEachRevUntilCases, getFindLastCases, getSearchRevCases, getReduceRevCases) for validating reverse operations on linear collections of integer pairs.
sequence_test.go, sequencecmp_test.go Updated builder type parameters from baseInternal[int] to linearInternal[int] in tests for reverse operations (e.g., EachRev, EachRevUntil, FindLast, FoldRev, ReduceRev, SearchRev).

Sequence Diagram(s)

sequenceDiagram
    participant T as Test Function
    participant B as Collection Builder
    participant L as Linear Collection
    participant M as Reverse Method
    T->>B: Build test collection
    B->>L: Instantiate linear collection
    T->>L: Invoke reverse method (e.g., EachRev, FindLast)
    L->>M: Process reverse operation
    M-->>L: Return computed results
    L-->>T: Deliver output for verification
Loading
sequenceDiagram
    participant F as comfyFindLast Function
    participant L as Linear Collection
    participant P as Predicate
    F->>L: Pass collection (Linear[V])
    L->>P: Evaluate each element against predicate
    P-->>L: Return boolean outcome
    L-->>F: Provide last matching value or default
Loading

Possibly related PRs

Poem

I'm a rabbit hopping through lines of code,
Clearing old tests off my winding road.
New methods sprout like carrots in the field,
Linear paths and reverse flows now revealed.
With a twitch of my nose and a joyful leap,
I celebrate these changes—hoping they reap!
🐇🥕 Happy coding, let innovation keep!

Warning

There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure.

🔧 golangci-lint (1.62.2)

Error: can't load config: the Go language version (go1.23) used to build golangci-lint is lower than the targeted Go version (1.24)
Failed executing command with error: can't load config: the Go language version (go1.23) used to build golangci-lint is lower than the targeted Go version (1.24)

Tip

⚡🧪 Multi-step agentic review comment chat (experimental)
  • We're introducing multi-step agentic chat in review comments. This experimental feature enhances review discussions with the CodeRabbit agentic chat by enabling advanced interactions, including the ability to create pull requests directly from comments.
    - To enable this feature, set early_access to true under in the settings.
✨ Finishing Touches
  • 📝 Generate Docstrings

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@codecov
Copy link
Copy Markdown

codecov bot commented Mar 16, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Files with missing lines Coverage Δ
definitions.go 100.00% <ø> (ø)
functions_internal.go 90.20% <100.00%> (ø)
🚀 New features to boost your workflow:
  • Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f2d566d and 926b8f2.

📒 Files selected for processing (6)
  • base_cases_test.go (0 hunks)
  • definitions.go (3 hunks)
  • functions_internal.go (1 hunks)
  • linear_cases_test.go (2 hunks)
  • sequence_test.go (4 hunks)
  • sequencecmp_test.go (4 hunks)
💤 Files with no reviewable changes (1)
  • base_cases_test.go
🧰 Additional context used
🪛 GitHub Check: test-and-lint
definitions.go

[failure] 48-48:
File is not properly formatted (gofumpt)

🪛 GitHub Actions: Pull Request Checks
definitions.go

[error] 1-1: File is not properly formatted (gofumpt)

🔇 Additional comments (33)
functions_internal.go (1)

86-104: Properly updated type constraint from Base[V] to Linear[V]

The function signature change correctly updates the type constraint to Linear[V], reflecting that reverse collection operations now belong to the Linear interface rather than Base. This is consistent with the interface restructuring where order-dependent operations are moved to the Linear interface.

sequence_test.go (6)

173-173: Updated type parameter to match the new interface requirement

The change from baseInternal[int] to linearInternal[int] correctly reflects that EachRev now requires collections to implement the Linear interface.


177-177: Updated type parameter to match the new interface requirement

The change from baseInternal[int] to linearInternal[int] correctly reflects that EachRevUntil now requires collections to implement the Linear interface.


190-191: Updated type parameters for FindLast test cases

The type parameter changes from baseInternal to linearInternal correctly reflect that FindLast operations now require collections to implement the Linear interface rather than just Base.


199-199: Updated type parameter to match the new interface requirement

The change from baseInternal[int] to linearInternal[int] correctly reflects that FoldRev now requires collections to implement the Linear interface.


232-232: Updated type parameter to match the new interface requirement

The change from baseInternal[int] to linearInternal[int] correctly reflects that ReduceRev now requires collections to implement the Linear interface.


254-255: Updated type parameters for SearchRev test cases

The type parameter changes from baseInternal to linearInternal correctly reflect that SearchRev operations now require collections to implement the Linear interface rather than just Base.

sequencecmp_test.go (6)

179-179: Updated type parameter to match the new interface requirement

The change from baseInternal[int] to linearInternal[int] correctly reflects that EachRev now requires collections to implement the Linear interface.


183-183: Updated type parameter to match the new interface requirement

The change from baseInternal[int] to linearInternal[int] correctly reflects that EachRevUntil now requires collections to implement the Linear interface.


195-195: Updated type parameter to match the new interface requirement

The change from baseInternal[int] to linearInternal[int] correctly reflects that FindLast now requires collections to implement the Linear interface.


203-203: Updated type parameter to match the new interface requirement

The change from baseInternal[int] to linearInternal[int] correctly reflects that FoldRev now requires collections to implement the Linear interface.


290-290: Updated type parameter to match the new interface requirement

The change from baseInternal[int] to linearInternal[int] correctly reflects that ReduceRev now requires collections to implement the Linear interface.


315-315: Updated type parameter to match the new interface requirement

The change from baseInternal[int] to linearInternal[int] correctly reflects that SearchRev now requires collections to implement the Linear interface.

linear_cases_test.go (17)

12-14: Well-defined types for linear collection test cases with pairs

These type definitions create a proper foundation for testing linear collections of pairs, consistent with the restructuring of the interface hierarchy.


16-78: Comprehensive test cases for EachRev operation

The implementation provides thorough test coverage for the EachRev operation, including empty collections, single-item collections, and multi-item collections. The test cases verify both the indices and values passed to the visitor function.


80-93: Robust test function for EachRev operation

This test function properly executes the test cases for the EachRev operation, validating the expected behavior for various collection states.


95-187: Comprehensive test cases for EachRevUntil operation

The implementation covers all important scenarios for EachRevUntil, including early termination in the middle of a collection. The test cases are well-designed to verify the correct behavior of the operation.


189-202: Robust test function for EachRevUntil operation

This test function properly executes the test cases for the EachRevUntil operation, validating the expected behavior for various collection states.


204-263: Comprehensive test cases for FindLast operation

The test cases thoroughly cover the FindLast operation for different collection sizes and predicate conditions, ensuring robust testing of the functionality.


265-275: Robust test function for FindLast operation

This test function properly executes the test cases for the FindLast operation, validating the expected behavior for various scenarios.


277-307: Well-designed test cases for FindLast with duplicate values

These test cases specifically target testing FindLast with collections containing duplicate values, ensuring that the operation correctly identifies the last matching element in a collection.


309-319: Robust test function for FindLast with duplicate values

This test function properly executes the test cases for the FindLast operation with duplicate values, validating the expected behavior in such scenarios.


321-368: Comprehensive test cases for FoldRev operation

The test cases cover various scenarios for the FoldRev operation, including empty collections, single-item collections, and multi-item collections, with different reducer functions.


370-380: Robust test function for FoldRev operation

This test function properly executes the test cases for the FoldRev operation, validating the expected behavior for various collection states.


455-582: Comprehensive test cases for SearchRev operation

The test cases thoroughly cover the SearchRev operation for different collection sizes and search conditions, including the handling of duplicates.


584-600: Robust test function for SearchRev operation

This test function properly executes the test cases for the SearchRev operation, validating all expected aspects of its behavior.


602-632: Well-designed test cases for SearchRev with pairs

These test cases properly verify the behavior of SearchRev with collections of pairs, ensuring that the operation works correctly with more complex data types.


634-647: Robust test function for SearchRev with pairs

This test function properly executes the test cases for the SearchRev operation with collections of pairs, validating the expected behavior in such scenarios.


649-679: Comprehensive test cases for ReduceRev operation

The test cases cover the important scenarios for ReduceRev, including empty collections (with error handling) and various non-empty collections.


681-694: Robust test function for ReduceRev operation

This test function properly executes the test cases for the ReduceRev operation, validating both the result value and error handling.

definitions.go (3)

114-130: Good job moving order-dependent methods to the Linear interface.

The migration of order-dependent methods like EachRev, EachRevUntil, FindLast, FoldRev, ReduceRev, and SearchRev from Base to Linear interface is excellent. This restructuring ensures that only collections guaranteeing element order provide these methods, which is architecturally sound.

The documentation comments on methods like FindLast are also clear and helpful.


138-139: Consider implementing the TODO methods or providing a timeline.

There are TODO comments for two search methods: SearchLastPos and SearchPos in the Indexed interface. Since these appear to be related to the refactoring of order-dependent methods, it would be helpful to either implement them or document when they'll be addressed.

Would you like to:

  1. Implement these methods in this PR?
  2. Create a separate issue to track them?
  3. Add more context about your plans for these methods?

129-130: Consider implementing the ValuesRev TODO method.

Similar to the other TODO comment, there's a ValuesRev() method marked with TODO. Since you've moved other reverse operations to the Linear interface, implementing this method would complete the set of reverse operations.

Would you like to implement this method now or create a tracking issue for it?

Comment on lines 47 to 106
type Base[V any] interface {

// Contains returns true if the collection contains an element that matches the predicate.
Contains(predicate Predicate[V]) bool

// Count returns the number of elements that match the predicate.
Count(predicate Predicate[V]) int

// Each iterates over the collection.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
// See also: EachUntil
Each(visit Visitor[V])
EachRev(visit Visitor[V])
EachRevUntil(valid Predicate[V])

// EachUntil iterates over the collection until the predicate returns false.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
// See also: Each
EachUntil(valid Predicate[V])

// Find returns the first element that matches the predicate, or the default value if no element matches.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
// See: Search
Find(predicate Predicate[V], defaultValue V) V
// FindLast returns the last element that matches the predicate, or the default value if no element matches.
// See: SearchRev
FindLast(predicate Predicate[V], defaultValue V) V

// Fold helps to fold a collection into a single value.
// Eg: Fold(func(acc int, i int, current int) int { return acc + current }, 0) // sum of all elements
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
Fold(reducer Reducer[V], initial V) (result V)
FoldRev(reducer Reducer[V], initial V) (result V)

// IsEmpty returns true if the collection is empty.
IsEmpty() bool

// Len returns the number of elements in the collection.
Len() int

// Search returns the first element that matches the predicate, or the default value if no element matches.
Search(predicate Predicate[V]) (val V, found bool)
// SearchLastPos(predicate Predicate[V]) (val V, found bool) // TODO
// SearchPos(predicate Predicate[V]) (val V, found bool) // TODO
SearchRev(predicate Predicate[V]) (val V, found bool)

// Reduce helps to reduce a collection into a single value.
Reduce(reducer Reducer[V]) (result V, err error)
ReduceRev(reducer Reducer[V]) (result V, err error)

// ToSlice returns a slice of all elements in the collection.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
ToSlice() []V

// Values returns an iterator over all elements in the collection.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
Values() iter.Seq[V]
// ValuesRev() iter.Seq[V] // TODO
}
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

⚠️ Potential issue

Interface refactoring looks good, but fix formatting issue on line 48.

The restructuring of the Base interface by adding methods like Contains, Count, Each, etc., and providing clear documentation for methods that are implicitly linear is a good design decision. This makes the interface more comprehensive for all collection types while clarifying behavior expectations.

However, there's a formatting issue at line 48 flagged by the pipeline: an empty line that doesn't meet Go formatting standards.

Run the following to fix the formatting:

-type Base[V any] interface {
-
+type Base[V any] interface {
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
type Base[V any] interface {
// Contains returns true if the collection contains an element that matches the predicate.
Contains(predicate Predicate[V]) bool
// Count returns the number of elements that match the predicate.
Count(predicate Predicate[V]) int
// Each iterates over the collection.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
// See also: EachUntil
Each(visit Visitor[V])
EachRev(visit Visitor[V])
EachRevUntil(valid Predicate[V])
// EachUntil iterates over the collection until the predicate returns false.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
// See also: Each
EachUntil(valid Predicate[V])
// Find returns the first element that matches the predicate, or the default value if no element matches.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
// See: Search
Find(predicate Predicate[V], defaultValue V) V
// FindLast returns the last element that matches the predicate, or the default value if no element matches.
// See: SearchRev
FindLast(predicate Predicate[V], defaultValue V) V
// Fold helps to fold a collection into a single value.
// Eg: Fold(func(acc int, i int, current int) int { return acc + current }, 0) // sum of all elements
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
Fold(reducer Reducer[V], initial V) (result V)
FoldRev(reducer Reducer[V], initial V) (result V)
// IsEmpty returns true if the collection is empty.
IsEmpty() bool
// Len returns the number of elements in the collection.
Len() int
// Search returns the first element that matches the predicate, or the default value if no element matches.
Search(predicate Predicate[V]) (val V, found bool)
// SearchLastPos(predicate Predicate[V]) (val V, found bool) // TODO
// SearchPos(predicate Predicate[V]) (val V, found bool) // TODO
SearchRev(predicate Predicate[V]) (val V, found bool)
// Reduce helps to reduce a collection into a single value.
Reduce(reducer Reducer[V]) (result V, err error)
ReduceRev(reducer Reducer[V]) (result V, err error)
// ToSlice returns a slice of all elements in the collection.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
ToSlice() []V
// Values returns an iterator over all elements in the collection.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
Values() iter.Seq[V]
// ValuesRev() iter.Seq[V] // TODO
}
type Base[V any] interface {
// Contains returns true if the collection contains an element that matches the predicate.
Contains(predicate Predicate[V]) bool
// Count returns the number of elements that match the predicate.
Count(predicate Predicate[V]) int
// Each iterates over the collection.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
// See also: EachUntil
Each(visit Visitor[V])
// EachUntil iterates over the collection until the predicate returns false.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
// See also: Each
EachUntil(valid Predicate[V])
// Find returns the first element that matches the predicate, or the default value if no element matches.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
// See: Search
Find(predicate Predicate[V], defaultValue V) V
// Fold helps to fold a collection into a single value.
// Eg: Fold(func(acc int, i int, current int) int { return acc + current }, 0) // sum of all elements
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
Fold(reducer Reducer[V], initial V) (result V)
// IsEmpty returns true if the collection is empty.
IsEmpty() bool
// Len returns the number of elements in the collection.
Len() int
// Search returns the first element that matches the predicate, or the default value if no element matches.
Search(predicate Predicate[V]) (val V, found bool)
// Reduce helps to reduce a collection into a single value.
Reduce(reducer Reducer[V]) (result V, err error)
// ToSlice returns a slice of all elements in the collection.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
ToSlice() []V
// Values returns an iterator over all elements in the collection.
// This method is implicitly linear on all collections that also implement the Linear interface.
// There is no guarantee that the order of elements will be preserved if the collection does not implement
// the Linear interface.
Values() iter.Seq[V]
}
🧰 Tools
🪛 GitHub Check: test-and-lint

[failure] 48-48:
File is not properly formatted (gofumpt)

@maciej-sz maciej-sz merged commit 8588425 into main Mar 16, 2025
3 of 4 checks passed
@maciej-sz maciej-sz deleted the feat/#13/move-ordered-methods branch March 16, 2025 15:21
Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (1)
definitions.go (1)

137-139: Consider prioritizing the TODO methods.

There are TODO comments for SearchLastPos and SearchPos methods in the Indexed interface. Since you're already restructuring interfaces to better represent order-dependent operations, it might be worth implementing these methods now to complete the refactoring.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 926b8f2 and 754cedf.

📒 Files selected for processing (1)
  • definitions.go (3 hunks)
🔇 Additional comments (3)
definitions.go (3)

47-104: Interface restructuring improves design clarity.

The restructuring of the Base interface with comprehensive documentation is excellent. By adding detailed explanations for methods like Each, EachUntil, Find, etc., you've clarified which operations are implicitly linear and which ones don't guarantee element order preservation. This makes the interface boundaries much clearer and will help users understand the behavior they can expect.

The addition of methods like Contains, Count, IsEmpty, Len, etc. to the base interface ensures that fundamental operations are available on all collections while keeping order-dependent operations separate.


115-129: Good migration of order-dependent methods to Linear interface.

Moving the reverse operation methods (EachRev, EachRevUntil, FindLast, FoldRev, ReduceRev, SearchRev) to the Linear interface aligns perfectly with the PR objective. These operations only make sense for collections that maintain element order, so this is the right place for them.

I notice there are TODO comments for potential future methods (LinearValues() and ValuesRev()). Consider creating issues to track these planned enhancements if they haven't been created yet.


48-48: Fixed formatting issue from previous review.

The formatting issue on line 48 that was flagged in the previous review has been properly addressed.

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.

1 participant