Concurrent Visualization Techniques in the VS2010 Profiler

See all videos in this series.
This looks like the "once" construct in Eiffel coupled with locking code for thread-safety.
It would be somewhat interesting to be able to do something like this
[Lazy] public int Expensive { get { return InsanelyExpensive(); } }
where the compiler will use the attribute to modify the code to use Lazy<int> underneath. This will make the laziness completely transparent to the caller, the transformed code will be something like this
public class LazyOrNot { private static T Slow<T>(T x) // why does this need to be static? { System.Threading.Thread.Sleep(3000); return x; } public int LetsPlay1 { get { return Slow(42); } } private Lazy<int> lazy = new Lazy<int>(() => Slow(42)); public int LetsPlay2 { get { return lazy.Value; } } [Lazy] public int LetsPlay3 { get { return LetsPlay1; } } }
Many interesting things possible...
Actually, I wonder if Lazy is the right name, given that a method is also "lazy" until evaluated but it does not memoize its result which is what this construct does I presume: evaluate once and remember, just like the Eiffel "once" (maybe Memo<T>; but Lazy<T> is more easily understood, probably)
What's the hype with the "lazy" word ?
Why not use "Cached" so everybody would understand it ?
Exoteric: why not as a keyword ?
public lazy int Expensive { get; }
public lazy int SomeMethod() { ... } // so it's only called once
Is there a way to invalidate the "cached" value ?
What happen when we use it with a deferred LINQ query ?
How I love our developer community.
You're right on the money -- lazy language integration would be sweet, so sweet in fact,
that F# has it. As for C#, it's certainly something that the C# team has and would considered but it takes a lot of effort and a lot of vetting to get a new feature into a language. The type hasn't even been RTMed yet! That said, the C# team always
loves feedback and feature requests:
Go to https://connect.microsoft.com/VisualStudio?wa=wsignin1.0, click "Submit Feedback for VS2010, then click "Submit a Suggestion"
Josh
ramoon,
Lazy is a pretty well-known CS concept and "Cached" doesn't seem to capture the most important function of the type -- you can have something that's eagerly evaluated and cached as well.
There is no way to invalidate a specific Lazy<T> instance. We wanted Lazy<T> to be as observationally pure as possible and behave just as if it were any other variable. For example, in C#, if you can't create an int of 4 and then invalidate it -- you simply reassign it. The same goes for a Lazy<int>.
As for LINQ query, I'm not sure I understand the question.. When you use a Lazy<T> in a LINQ or PLINQ query, it will be evaluated whenever the execution occurs Value is called.
Hope that helps!
Josh
Actually, not having implemented attributes myself, I assumed that you could create a C# attribute and setup a code transformation "pipeline" (chained attributes?) to transform the source code into something where the function is memoized, but I guess this is something the C# team is investigating. I'd rather have that than another keyword.
It reminds me of D where you can do compile-time function execution and string manipulation (actually you could build a compile-time parser that builds an AST, does code-transformation and outputs the transformed source code, all at compile-time). C# would hopefully let you do that directly. Well, it's not *that* important, just interesting.
This Lazy type is very nice and I'll probably be using it here and there. In a similar fashion I made the Unnullable type but I think it would be cool if somehow these types could cloak themselves as their nested types so you didn't "see" them - but that would require compiler support as above.
Whoa! We'll be able to clean up a lot of our code. We currently have that pattern all over the place.
so, in MEF there is a Lazy<T,TMetadata> will that go into the bcl as well?
also, it would really be helpful to have implicit operators between Lazy<T> and T
Hi aL_,
Lazy<T,TMetadata> actually extends Lazy<T> and no it won't end up in BCL, for Beta 2, it's actually in System.ComponentModel.Composition. We'd considered the implicit cast operator but because we're executing arbitrary code we determined that's a bad idea. It's only complicated by the fact that the valueFactory delegate may thrown an exception.
Thanks for the feedback!
Josh