The new new lazy loader

This is easy?

JD — Sat, 08 May 2004 14:07:00 GMT

This is an interesting exploration of using generic programming.

Pardon the naivete, but how does this make the resulting code any better? I suppose that it's better to avoid re-implementing Lazy Loading in every place it's used.

This is quite complex though, and I consider the code written in the class to be much less readable than it would if the lazy-loading were encapsulted in a single method on the class. I'd like to see a sample that uses an instance (not static) creator doing some reasonably instance-based work (instead of using a constant string for the bitmap), and compare it to the corresponding code without LazyLoader.
Again, maybe I'm just missing the point and need it banged in with samples. I like the investigation regardless, very interesting.

Side question; do you use Optional instead of Nullable for a reason?

re: The new new lazy loader

Kevin Pilch-Bisson — Sat, 08 May 2004 20:21:00 GMT

Nullable<T> is being changed to only be allowed for ValueTypes later in Whidbey. The reason for this is that the language designers want to avoid seeing API's introduced that take Nullable<string>, and the resulting fracturing that can occur.

re: The new new lazy loader

jaybaz [MS] — Sun, 09 May 2004 00:13:00 GMT

The code we wrote here violates YAGNI. We've written a lot of generality in that we don't know we need. The LazyLoader class varies on 3 axes:

1. Locked or not.
2. Weak or strong reference.
3. delegate construction or new() construction

If you remove one of these features by selecting the option on the left, the class becomes much simpler. If you always select the option on the right, the difference is small.

If you have a need for exactly one combination of these features, you could write that in less code. If you only need it once, you could write it in place, without a new class.

If you need that specific combination in 20 places in your app, and no other combo, then a class that supported exactly that, with no options, would make your code well factored.

If you need the flexibility of all 3 of the above options, then I think the code we've written is about as clear as it possibly can be, with the least duplication. What we've done is write a very full-featured solution, as simply as possible. We're acting like library writers, not application writers. App writers should write the simplest solution, as simply as possible.

It does assume that the reader is comfortable with generics, delegates, an OO concepts. I think that's a perfectly reasonable assumption.

re: The new new lazy loader

Cyrus Najmabadi — Tue, 11 May 2004 00:46:00 GMT

JD:

When Kevin Jay and I wrote the initial implementation, we were trying to see if it was possible to cleanly and usuably extract the following common pattern from your source:

public T SomeProperty {
get {
lock (this) {
if (!someField.IsInitialized) {
someField.Initialize();
}
}

return someField;
}
}

However, the locking, testing and initialization can be arbitrarily complex (although in most cases it's just the initialization that's complex).

However, after writing that I realized that this wouldn't be useful for me. Why? Because a large number of my lazy loaded properties are, in fact, weakly referenced. I don't want to create them until necessary (costly to create) and i don't want to keep them when the system is under memory pressure (costly to maintain). So I end up writing this code quite often:

private WeakReference cachedFoo;
public T Foo{
get {
lock (this) {
T foo = default(T);
bool initialized = false;
if (cachedFoo != null) {
object o = cachedFoo.Target;
if (o != null) {
foo = (T)o;
initilized = true;
}
}

if (initialized == false) {
foo = SomeComplexBitOfCode();
cachedFoo = new WeakReference(foo);
}

return foo;
}
}
}

That's some pretty ugly code. It's much much much uglier when you have 10 properties.

Now I can replace it with:

private Creator<T> getFoo = LazyLoaderCreator.Create<T>(false, true, elegate { return SomeComplexBitOfCode(); });
public T Foo {
get {
return getFoo();
}
}

Now, all the locking and referencing issues are taken care of for me. All i need to care about is the initialization logic. That's a savings of 15 identical lines every time i need this pattern.

As Jay said above, this was not meant to solve a specific application's needs. Rather, we wanted to provide a library that people could use in their own application to solve all of these needs.

Note: No user ever need be concerned with the implementation of LazyLoader, IOptional, ILock, or IReference. Rather, they should only care about these following two things:

delegate A Creator<A>();
and
public static Creator<A> LazyLoaderCreator.Create<A>(Creator<A> create);

And that method basically says "Given a function that will create an A, i will give you back a function that when invoked will lazily create an A and then return that on successive calls".

So the complexity that you see is, IMO, the complexity that we've kept you from having to introduce into your own class _every_ place you need lazy loading.

re: The new new lazy loader

Cyrus Najmabadi — Tue, 11 May 2004 00:47:00 GMT

Sorry if the above comment is hard to read (both codewise and grammarwise). Looks like you can't edit a comment after you've posted. If anyone would like me to clarify anything about that, please let me know.

First blog entry

Cyrus' WebLog — Sun, 16 May 2004 01:38:00 GMT

So many posts in so little time...

Code/Tea/Etc... — Mon, 17 May 2004 09:53:00 GMT

Theo schools me on OO over functional programming

Cyrus' Blather — Wed, 19 May 2004 08:31:00 GMT

Theo schools me on OO over functional programming

Cyrus' Blather — Wed, 19 May 2004 09:20:00 GMT

re: The new new lazy loader

JD — Wed, 19 May 2004 18:02:00 GMT

I appreciate the explanation that shows the code you wanted to replace with it. I'm more concerned about the readbility and usability of the code that the user sees:

private Creator<T> getFoo
= LazyLoaderCreator.Create<T>(false, true, delegate { return SomeComplexBitOfCode(); });

public T Foo {
get { return getFoo(); }
}

I don't think my dislike for this code is based soley on its use of generics. Maybe some of it is naming. Creating a creator, the bool params, even the delegate (though I understand that's the most general case),

private LazyLoader<T> lazyGetFoo
= LazyLoaderCreator.Create<T>();

public T Foo {
get { return lazyGetFoo(); }
}

With overloads:
LazyLoaderCreator.CreateLoaderWithLocks<T>()
LazyLoaderCreator.CreateLoaderWithWeakReferences<T>()
LazyLoaderCreator.CreateLoaderWithLocksAndWeakReferences<T>()

Those aren't the best either, maybe enums, maybe some other factorization that makes clearer what the code is doing. The maintenance programmer isn't going to understand your brilliance without some help, is all.

re: The new new lazy loader

jaybaz [MS] — Wed, 19 May 2004 19:55:00 GMT

JD: I hear ya. I've had some of the same concerns, but not sure where to go with it next.

We'll keep pondering.

Singleton Pattern

More .NET Yumminess — Fri, 21 May 2004 10:01:00 GMT

Actors and Actresses » Archive du blog » jaybaz [MS] WebLog : The new new lazy loader

Fri, 04 Jan 2008 23:46:43 GMT

PingBack from http://actors.247blogging.info/?p=4241

Dinner and a Movie » jaybaz [MS] WebLog : The new new lazy loader

Dinner and a Movie » jaybaz [MS] WebLog : The new new lazy loader — Thu, 20 Mar 2008 23:32:55 GMT

PingBack from http://dinnermoviesblog.info/jaybaz-ms-weblog-the-new-new-lazy-loader/

jaybaz MS WebLog The new new lazy loader | fix my credit

jaybaz MS WebLog The new new lazy loader | fix my credit — Wed, 17 Jun 2009 05:40:52 GMT

PingBack from http://fixmycrediteasily.info/story.php?id=4662