Skip to content

Change ExecuteUpdate to accept Action instead of Func parameter#35455

Merged
roji merged 2 commits intodotnet:mainfrom
roji:MoreExecuteUpdate
Jan 13, 2025
Merged

Change ExecuteUpdate to accept Action instead of Func parameter#35455
roji merged 2 commits intodotnet:mainfrom
roji:MoreExecuteUpdate

Conversation

@roji
Copy link
Member

@roji roji commented Jan 12, 2025

This is a small follow-up to #35257, so part of #32018 (/cc @AndriySvyryd).

This changes ExecuteUpdateAsync to accept an Action instead of a Func, following @aradalvand's suggestion here. This improves the developer experience further, removing the need to have a return at the end of the provided lambda. This required some non-trivial changes to CSharpToLinqTranslator, since ExecuteUpdateAsync now expects an Action<UpdateSettersBuilder> parameter, but the translated lambda type was currently determined by the body, and so was Func<UpdateSettersBuilder, UpdateSettersBuilder>.

This also renames the oddly-named SetPropertyCalls to UpdateSettersBuilder, which better expresses what that type really is (it really is just a builder, which accumulates setter lambda pairs). This is technically an additional breaking change, but any scenario in which SetPropertyCalls was explicitly referenced is already broken by #35257 - so this rename shouldn't in itself affect anyone.

@roji roji requested a review from a team January 12, 2025 10:21
_ => Visit(node),
};

// TODO: Insert necessary Convert nodes etc. when the expected and actual types differ
Copy link
Member

Choose a reason for hiding this comment

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

Add issue #

Copy link
Member Author

@roji roji Jan 13, 2025

Choose a reason for hiding this comment

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

Unless you have strong feelings about this, I'd rather not systematically pollute our repo with every TODO that I put in code... In many cases that's useful, but in cases like this I really don't see the value of it, and would rather not do it just because we have a rule... Let me know - I'd ultimately rather remove the TODO, but I don't think that's a positive thing.

Copy link
Member

Choose a reason for hiding this comment

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

We can discuss this again, but generally, non-tracked TODO comments make the code look less professional and usually don't have enough context to properly reason about for someone else. I'd much rather have an issue with a checklist of all the small changes in an area so that they can be discussed and prioritized

Copy link
Member Author

Choose a reason for hiding this comment

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

OK, sure thing. I guess I don't generally consider TODO comments as looking unprofessional (regardless of whether they reference an issue or not), and I'm just looking to reduce process and needless issues. CSharpToLinqTranslator specifically is an extreme case as there really are a lot of unimplemented cases (many theoretical, some less so).

But I'm open to doing as you say here, maybe e.g. a single issue for all pending CSharpToLinqTranslator isn't too bad.

@roji roji merged commit 38dc78f into dotnet:main Jan 13, 2025
7 checks passed
@roji roji deleted the MoreExecuteUpdate branch January 13, 2025 21:52
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.

2 participants