15 minutes ago, blowdart wrote
@Charles I will buy you lunch if your first question is
"Immutable collections - does this change everything?"
Also ask if the immutable classes might change in future ![]()
Loading User Information from Channel 9
Something went wrong getting user information from Channel 9
Loading User Information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
15 minutes ago, blowdart wrote
@Charles I will buy you lunch if your first question is
"Immutable collections - does this change everything?"
Also ask if the immutable classes might change in future ![]()
Sounds cool. ![]()
I would love if you could ask
1. Why did they choose the NUGET mechanism for the ImmutableCollections feature. Is this something we should expect going forward for other features from them ![]()
2. What made them choose using NUGET over VISUAL STUDIO EXTENSIONS.
3. What is the next step from this preview, or more importantly how do they envision the roadmap for these NUGET delivered features...
4. How do these features finally make there way into .NET framework?
Thank you, Niners. Keep the questions coming! I'll make sure we set aside quality time to address as many as possible.
We will try to keep this under an hour (I have to leave at 435 to get to a meeting in another building by 445). The camera will continue to roll regardless. ![]()
C
Does this use research results like finger trees?
Is the primary motivation practical in the sense of invariants or also geared towards compiler tricks?
1 hour ago, exoteric wrote
Does this use research results like finger trees?
Is the primary motivation practical in the sense of invariants or also geared towards compiler tricks?
Good question ... if all the types in use are in immutable collections, and all the computations on those immutable collections are within LINQ computations, could the compiler assume purity and therefore allow laziness and referential transparency by default in those cases?
Jan 09, 2013 at 7:45 PM, LiquidBoy wrote
I would love if you could ask
Sorry for the late reply -- I completely missed the second page ![]()
1. Why did they choose the NUGET mechanism for the ImmutableCollections feature.
We chose NuGet for two reasons. Firstly, since Visual Studio 2012, the package manager is available out-of-the-box. And, more importantly in my mind, NuGet has already a huge community.
Is this something we should expect going forward for other features from them
Yes. In fact, we 've already shipped two .NET 4.5 components this way: MEF and TPL Dataflow. They aren't in preview anymore and are treated as any other .NET Framework component that ships together with the redist. For example, it's fully supported.
2. What made them choose using NUGET over VISUAL STUDIO EXTENSIONS.
NuGet is for libraries, Visual Studio Extensions is about tooling, i.e. extending Visual Studio itself. For example, the NuGet Package Manager is a Visual Studio Extension.
3. What is the next step from this preview, or more importantly how do they envision the roadmap for these NUGET delivered features...
We are still figuring out the exact details but our goal is investing more and more in out-of-band delivered components.
4. How do these features finally make there way into .NET framework?
If you're asking if we plan to eventually treat them as a fully supported .NET Framework components, then the answer is yes. If your question is whether we plan on redistributing them via the .NET Framework setup, then the answer is no.
Add your 2¢