Skip to content

Add support for using a CodeBlock as a value to generate #34759

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
snicoll opened this issue Apr 15, 2025 · 1 comment
Closed

Add support for using a CodeBlock as a value to generate #34759

snicoll opened this issue Apr 15, 2025 · 1 comment
Assignees
Labels
status: declined A suggestion or change that we don't feel we should currently apply theme: aot An issue related to Ahead-of-time processing type: enhancement A general enhancement

Comments

@snicoll
Copy link
Member

snicoll commented Apr 15, 2025

When transforming data in custom code, it would be beneficial to be able to reuse the built-in converters while being able to take control over an element of the chain.

An example is Map<String,T> where T is written as a local variable. Once that's done, it should be possible to let the generator write the code for Map<String,TheNameOfTheField> but such indirection isn't possible at the moment.

Checking if the value is a CodeBlock and then render that as is should help as code generation doesn't have to comply with the actual type of what the generated code represents.

@snicoll snicoll added theme: aot An issue related to Ahead-of-time processing type: enhancement A general enhancement labels Apr 15, 2025
@snicoll snicoll added this to the 7.0.0-M4 milestone Apr 15, 2025
@snicoll snicoll self-assigned this Apr 15, 2025
@snicoll
Copy link
Member Author

snicoll commented Apr 15, 2025

Reviewing this in detail, there's an easy way to break things, especially for collections as they tend to be generated in separate methods that don't carry the context. For cases like this, it's better to create an empty Map and loop over them to add the entries. This also avoids problem of having to assign a field name with something that may not be a valid identifier.

@snicoll snicoll closed this as not planned Won't fix, can't repro, duplicate, stale Apr 15, 2025
@snicoll snicoll added the status: declined A suggestion or change that we don't feel we should currently apply label Apr 15, 2025
@snicoll snicoll removed this from the 7.0.0-M4 milestone Apr 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply theme: aot An issue related to Ahead-of-time processing type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

1 participant