Skip to content

refactor(dsl)!: Replace buildXxx functions with TypeName { } companion invoke pattern#534

Closed
kpavlov wants to merge 7 commits into
mainfrom
kpavlov/change-dsl
Closed

refactor(dsl)!: Replace buildXxx functions with TypeName { } companion invoke pattern#534
kpavlov wants to merge 7 commits into
mainfrom
kpavlov/change-dsl

Conversation

@kpavlov
Copy link
Copy Markdown
Contributor

@kpavlov kpavlov commented Feb 18, 2026

Replace buildXxx functions with TypeName { } companion invoke pattern

  • Replace top-level buildXxx { } DSL entry-point functions with TypeName.Companion.invoke operators across DSL files

  • Call sites now read CallToolResult { ... } instead of buildCallToolResult { ... }, which reads more naturally and avoids top-level namespace pollution for library users

  • Update all test and integration files to use the new syntax. Kept old tests for deprecated methods.

  • Introduced ToolsResultDslTest and PromptsResultDslTest to test result builders for tool and prompt operations.

  • Added buildCompleteResult and buildInitializeResult for server-side result creation.

  • Updated API surface to include result DSL functionality.

  • Added new test cases for CallToolResult, ListResourcesResult, and ReadResourceResult to validate error handling, structured content, and metadata processing.

  • Improved coverage for resource and template handling with additional edge cases for mixed-field resources and pagination

  • Updated integration tests to use the buildCallToolResult DSL for constructing results, improving clarity and reducing boilerplate. Added @OptIn(ExperimentalMcpApi::class) annotations to test files requiring experimental API.

  • Refactored delay handling in tests to streamline coroutine usage.

Motivation and Context

Top-level buildXxx functions bloat the global scope for every user of the library. Scoping DSL entry points to companion objects (TypeName { }) is idiomatic Kotlin — consistent with how buildList, buildMap etc. work in stdlib, but anchored to a type rather than a free function.

Incorporates chandes from #530

How Has This Been Tested?

Unit/integration tests

Breaking Changes

Yes, DSL shape has changed

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

See discussion from #530

@kpavlov kpavlov added the breaking Breaking changes label Feb 18, 2026
@kpavlov kpavlov added this to the 0.9 milestone Feb 18, 2026
@kpavlov kpavlov requested review from devcrocod and e5l February 18, 2026 16:17
@kpavlov kpavlov marked this pull request as ready for review February 18, 2026 16:30
@kpavlov kpavlov added the refactoring Code improvements and refactoring label Feb 18, 2026
…dation

- Introduced `ToolsResultDslTest` and `PromptsResultDslTest` to test result builders for tool and prompt operations.
- Added `buildCompleteResult` and `buildInitializeResult` for server-side result creation.
- Updated API surface to include result DSL functionality.
…SL across integration tests

- Updated integration tests to use the `buildCallToolResult` DSL for constructing results, improving clarity and reducing boilerplate.
- Added `@OptIn(ExperimentalMcpApi::class)` annotations to test files requiring experimental API.
- Refactored delay handling in tests to streamline coroutine usage.
- Added new test cases for `CallToolResult`, `ListResourcesResult`, and `ReadResourceResult` to validate error handling, structured content, and metadata processing.
- Improved coverage for resource and template handling with additional edge cases for mixed-field resources and pagination.
- Added `.toList()` defensive copying in `build()` methods to ensure immutability of returned collections.
- Enhanced documentation for CallToolResult, metadata, and field nullability to align with MCP serialization conventions.
…ke` for cleaner DSL usage

- Deprecated `build*Request` functions across DSLs in favor of the `Companion.invoke` operator.
- Updated all documentation, examples, and tests to reflect the new syntax.
- Improved clarity, reduced redundancy, and streamlined API usage.
@kpavlov kpavlov marked this pull request as draft February 19, 2026 06:26
@kpavlov kpavlov marked this pull request as draft February 19, 2026 06:26
…anion.invoke` and update tests

- Added deprecation annotations to `build*Request` methods across all relevant DSLs with migration guidance.
- Updated associated test cases and documentation to use the new `Companion.invoke` syntax.
- Extract subscription DSLs from resources.dsl.kt into subscriptions.dsl.kt
@kpavlov kpavlov marked this pull request as ready for review February 19, 2026 06:59
Copy link
Copy Markdown
Contributor

@devcrocod devcrocod left a comment

Choose a reason for hiding this comment

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

Please avoid using invoke, especially on a companion object
it resolves very badly

@devcrocod
Copy link
Copy Markdown
Contributor

I think we should hold a design meeting on this
or open a separate discussion to go over the API

@kpavlov kpavlov marked this pull request as draft February 20, 2026 11:20
@e5l e5l removed their request for review March 9, 2026 13:47
@kpavlov kpavlov modified the milestones: 0.9, 0.12 Mar 26, 2026
@devcrocod
Copy link
Copy Markdown
Contributor

Closing this for now with a few concerns:

  1. The scope is too large to review confidently as a single PR
  2. It mixes two separate things: the buildXxx → TypeName { } migration and new result builders from feat(dsl): add result DSL builders #530. Would be easier to review those independently
  3. Changing the DSL entry-point pattern across the whole public API is a big design call. Would be good to hash that out in an issue first before jumping to implementation

@devcrocod devcrocod closed this Apr 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

breaking Breaking changes refactoring Code improvements and refactoring

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants