Skip to content

Expression mapper#951

Closed
ranma42 wants to merge 2 commits into
riok:mainfrom
ranma42:feat/expressions
Closed

Expression mapper#951
ranma42 wants to merge 2 commits into
riok:mainfrom
ranma42:feat/expressions

Conversation

@ranma42

@ranma42 ranma42 commented Nov 25, 2023

Copy link
Copy Markdown

Expression mappers

Description

Implement the Expression<Func<A, B>> map generation.

This is a WIP attempt at extending the source generator.
The code is most likely NOT ready for a review (yet 😇 ).

Fixes #733

Checklist

  • The existing code style is followed
  • The commit message follows our guidelines
  • Performed a self-review of my code
  • Hard-to-understand areas of my code are commented
  • The documentation is updated (as applicable)
  • Unit tests are added/updated
  • Integration tests are added/updated (as applicable, especially if feature/bug depends on roslyn or framework version in use)

The code is kind of working, but it contains an ugly hack, as the
methods that return `Expression`s are not supposed to have any input.
@ranma42 ranma42 changed the title Feat/expressions Expression mapper Nov 25, 2023
@ranma42

ranma42 commented Nov 25, 2023

Copy link
Copy Markdown
Author

I managed to get #733 mostly working but I need some directions on how to approach a couple of issues.

Specifically, I am hacking around the fact that the expr methods are not supposed to have a source in ranma42@53e62b1#diff-39772ddec5eba09b32838264b5f579c437ce1452f4c4a8f5f3d3f2ad1779bbcfR280-R281 and again in ranma42@53e62b1#diff-6771c2c8998836aea4afc8eec9c5d28109aa1544052ef52756889fcc6e7cba99R59

What is the right approach here?
I can see several ways forward, but I am not sure what is the right approach. Some proposals:

  • should have a fake source parameter of type void (injected when extracting, dropped when emitting)
  • should extend the code to allow null as source parameter
    Right now my commit follows the first approach, as it results in a smaller impact in the codebase.

A related issue I am unsure about is: for expression mappers, do we expect the types to be:

  • source: void, dest: expr<func<A,B>>, or
  • source: A, dest: B ?
    I was afraid that the second approach would risk conflicts when looking up existing mappers and make it hard/impossible for users to provide their own implementations, so I went with the first one.

Sorry if I opened this as a (draft) PR even though it is not yet ready for review (and most checklist requirements are not met), but I thought it would be easier to ask for directions on these with the code on the side

@latonz

latonz commented Dec 2, 2023

Copy link
Copy Markdown
Contributor

@ranma42 thank you for your efforts!
I haven't done a detailed review of the code yet, but your decisions sound reasonable. I'm not sure about the void source parameter though 🤔 At first glance it looks a bit "hacky"... Especially parts like source ?? LiteralExpression(SyntaxKind.NullLiteralExpression); in the TypeMappingBuildContext or SourceParameter = sourceParameter.Ordinal >= 0 ? sourceParameter : null in the MethodMapping. IMO the "more correct" way would be to set the source parameter nullable. I haven't tried it out, not sure what implications it has on the rest of the source code.

@latonz

latonz commented Mar 11, 2024

Copy link
Copy Markdown
Contributor

Closing for now as no updates were provided for a longer time period. I would be happy to review a new PR with updates, feel free to open a new PR if you plan to continue your work on this.

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.

Allow creating an Expression<Func<>> instead of a IQueryable Projection

2 participants