Skip to content

Conversation

@joseharriaga
Copy link
Collaborator

@joseharriaga joseharriaga commented Aug 25, 2025

All the classes derived from ResponseItem now have public constructors, and these constructors are generated.

A side effect of making these classes behave as both, inputs and outputs, was that their required properties got setters. Setters make sense when the values of these properties can be updated, but in this particular case they should only be settable at construction time. This is a limitation in the code generator being tracked by the following issue:
🔗 microsoft/typespec#5175 (comment)

public FileSearchCallResponseItem(IEnumerable<string> queries);
public IList<string> Queries { get; }
public IList<FileSearchCallResult> Results { get; }
public IList<FileSearchCallResult> Results { get; set; }
Copy link
Collaborator

Choose a reason for hiding this comment

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

I believe we don't provide setter for collection properties? is it not the case here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, this is correct. See my comment in PR description. This is a limitation in our codegen, but since this is experimental, I don't think it should be a blocker. 🙂

@joseharriaga joseharriaga force-pushed the joseharriaga/ItemConstructors branch from c10d11d to c1b73b5 Compare August 27, 2025 21:58
@joseharriaga joseharriaga merged commit 4376162 into main Aug 28, 2025
1 check passed
@joseharriaga joseharriaga deleted the joseharriaga/ItemConstructors branch August 28, 2025 00:14
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.

3 participants