Skip to content
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

Closed
shaggygi opened this issue Apr 14, 2017 · 12 comments
Closed

[Question/Proposal] Immutable Parent Child API #21099

shaggygi opened this issue Apr 14, 2017 · 12 comments
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Collections design-discussion Ongoing discussion about design without consensus
Milestone

Comments

@shaggygi
Copy link
Contributor

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:

  1. See if there is already related capabilities included with .NET Standard (or elsewhere compatible with .NET Standard) or
  2. Possibly start the conversation/action to add this as a first-class offering with .NET Standard.

FYI... @terrajobst, @AArnott, @ericlippert, @davidfowl, @stephentoub, @danmosemsft, @weshaggard,
@KrzysztofCwalina, @karelz, @MadsTorgersen

I really appreciate any help with my question/proposal. Thanks in advance.

@AArnott
Copy link
Contributor

AArnott commented Apr 14, 2017

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?

@shaggygi
Copy link
Contributor Author

shaggygi commented Apr 14, 2017

@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).

The error... "Error The "GenerateCodeFromAttributes" task failed unexpectedly."

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.

@AArnott
Copy link
Contributor

AArnott commented Apr 14, 2017

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.

@AArnott
Copy link
Contributor

AArnott commented Apr 14, 2017

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.

@shaggygi
Copy link
Contributor Author

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 using ImmutableObjectGraph.Generation;

Thanks for code generation link (man, that's a long discussion). Looks promising though.

@karelz
Copy link
Member

karelz commented Apr 14, 2017

So what are we tracking in this issue? Or is everything important tracked in the linked issues already?

@shaggygi
Copy link
Contributor Author

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.

@AArnott
Copy link
Contributor

AArnott commented Apr 14, 2017

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.

@AArnott AArnott closed this as completed Apr 14, 2017
@shaggygi
Copy link
Contributor Author

Before closing, let me ask where it would be appropriate to request elsewhere. Roslyn, CoreFxLab, other repo?

@AArnott
Copy link
Contributor

AArnott commented Apr 14, 2017

@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.

@shaggygi
Copy link
Contributor Author

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.

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 2.0.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Collections design-discussion Ongoing discussion about design without consensus
Projects
None yet
Development

No branches or pull requests

4 participants