-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[Question/Proposal] Immutable Parent Child API #21099
Comments
This sounds like what is available via the ImmutableObjectGraph, which I introduce in this blog post. Does that sound like it captures what you're going for? |
@AArnott Thanks for reply/reference. ImmutableObjectGraph seems interesting, but appears to have some overhead in project to generate other code. Plus, I did a quick NuGet reference in a WPF app and could not build (without adding any code).
While I don't know how an ideal Immutable parent/child API would look like, I really appreciate how Roslyn's SyntaxNode looks/feels. It is nice having the Parent, Tree (to get Root) and extensions for search up and down the tree. I'll keep tinkering around with ImmutableObjectGraph. Thanks again. |
Sorry about the build error. As Roslyn doesn't have first-class support for code generation extensions yet, I have to get creative with MSBuild and it can be really hard to keep it working for all scenarios at once. WPF in particular has a double-build oddity that no other project type has. Can you try it in a console app or unit test project first? This project isn't an official Microsoft project. But it produces a set of classes rather similar to Roslyn's SyntaxTree approach. From what I understand, they use code generation to create that tree as well, although their generation was based on xml the last I heard whereas ImmutableObjectGraph lets you write normal C# code as the template. Certainly first-class language support for something like this could lead to a premium experience, but internally I think the compiler would still need to generate a ton of code. I haven't thought of a way for mere libraries like these immutable collections to help you with trees of types. |
See dotnet/csharplang#107 for a discussion on a language feature for code generation. There's a lot of good stuff in the older issue it links to as well. |
I get same error with a .NET Console app. Appears I can build using .NET Core Class project, but doesn't seem to pick up the Thanks for code generation link (man, that's a long discussion). Looks promising though. |
So what are we tracking in this issue? Or is everything important tracked in the linked issues already? |
I believe we should track the effort in creating an Immutable parent/child API. From what I've read in the links so far, it seems like discussions related technologies that may or may not enable a better experience with the requested API. I believe the work @AArnott did with his noted repo above might be a starting point and then move into corefx later. He would need to offer insight there. |
I don't think there's anything for corefx to deliver here. It's unlikely ImmutableObjectGraph will mature into a corefx feature anytime soon (if it were ever even appropriate to) and it's more likely that an official supported feature for this would come from the language. So I'll close this. |
Before closing, let me ask where it would be appropriate to request elsewhere. Roslyn, CoreFxLab, other repo? |
@shaggygi I'm not clear on what question you're asking. It sounds like you want to create type trees like what you find in Roslyn's SyntaxTree but with your own types. If so, it's as I said: the only way this has ever been done for .NET is via build-time code generation. And you can see how Roslyn does it (xml based) in their repo, you can look at or reuse ImmutableObjectGraph, or you can track the csharplang issue that tracks making a language feature for code generation. You might file your own csharplang issue asking for the specific feature that you're requesting here and see how they respond to it. I just don't think a library (alone) will be able to offer what you're asking for. |
Ok. Thanks for the links to your repo and code generation discussions. I'll take the time to review and then follow up on the cslang repo. |
This is a question (or possibly a proposal of new feature) to have the ability to manage immutable parent/child(ren) hierarchies efficiently with .NET Standard. I've searched various sites, blogs and the topic appears to be somewhat complex... at least from my country bumpkin perspective 😄
I came across the @AArnott and @terrajobst video/blog, read @ericlippert's blog on topic and attempted to understand Roslyn's SyntaxNode/GreenNode implementation (which is far more complex than my needs/comprehension).
I think the System.Immutable.Collections APIs are an incredible start and provide great capabilities. However, they appear to stop short of offering similar parent/child management. It would be nice to have an additional immutable parent/child API.
This parent/child relationship is nothing more than similar discussions on Stack Overflow. I (like many others) need the ability to instantiate immutable parent objects, attach child(ren) objects, search up/down the tree (ancestors/descendants) and most importantly... update the objects' relationship when adding/updating/removing objects respectively (upstream or downstream). Meaning, once a child has been modify... the Parent is updated accordingly.
I'm including a few of the smarter peeps I could think of to reach out to:
FYI... @terrajobst, @AArnott, @ericlippert, @davidfowl, @stephentoub, @danmosemsft, @weshaggard,
@KrzysztofCwalina, @karelz, @MadsTorgersen
I really appreciate any help with my question/proposal. Thanks in advance.
The text was updated successfully, but these errors were encountered: