Objective-C: What is a lazy class?

Question

Looking at the Objective-C runtime library source code, particularly at objc-runtime-new.mm, I saw some functions and even comments which referred to lazy and non-lazy classes. It seems that classes that don't have a +load method are called lazy classes, but I'm not sure of that and most likely that is not right. After searching on Google, I didn't found anything about lazy classes on Objective-C.

So, what is a lazy class in Objective-C? Does Obj-C have this feature? Is it related to the presence of a +load method in a class' implementation? At the file linked above, the runtime system calls a function called _getObjc2NonlazyClassList in order to get a list of non-lazy classes from an image. Why isn't there a _getObjc2LazyClassList function too?

Answer 1

I found the answer: It's all about a class implementing or not a +load method.

All the classes implemented in a given image file have a reference in a list stored in the "__DATA, __objc_classlist, regular, no_dead_strip" binary's section. This list allows the runtime system to keep track of all the classes stored in such file. However, not all of the classes need to be realized when the program starts up. That's why when a class implements a +load method, it also has a reference in a list stored in the "__DATA, __objc_nlclslist, regular, no_dead_strip" section.

So, _getObjc2NonlazyClassList retrieves the list of classes that do implement a +load method and are so called non-lazy. _getObjc2ClassList retrieves a list of all the classes in a image file, including the classes that don't have a +load method (and are called lazy) and the non-lazy ones. Non-lazy classes must be realized when the program starts up. Lazy classes, on the other hand, don't need to be realized immediately. This may be delayed until the class receives a message for the first time, for example (that's the reason for them to be considered "lazy").

The same is true for categories, by the way.

Answer 2

"Lazy" is used in two different contexts.

The first, when critiquing a class design, argues that a class is ineffectual -- that it doesn't do enough to justify its existence. People also call this kind of class "thin." This is probably not what you mean here.

Second, lazy evaluation and lazy instantiation mean that the class only does the work of evaluating a property or initializing itself when actually needed.

For example, suppose we have a class that makes an Employee object.

 @implementation Employee
 - (id) initWithID: (IdentificationCode*) ident
 {
    self =[super init]
    if (self) {
         _records=[self retrieveEmployeeRecordsFor: ident];
         _identification=ident;
         }
    return self;
}

This is fine, but retrieving all the records from a database might be slow. And sometimes we don't need to do the work. For example:

- (BOOL) isFounder
{
     if (indent.number<10) return YES;
     return NO;
}

If we're instantiating an Employee simply to find out if they're a Founder, we don't need to look up their records at all!

 .....
 if ([thisEmployee isFounder]) {
      [self sendCandyTo: thisEmployee.identification];
      }

On the other hand, sometimes we need them:

- (NSArray*) payments
{
    return [self.records retrievePayStubs];
    }

So, if we're constructing an Employee just to call isFounder, we waste a database lookup. But we can't just skip that, because payments needs it.

What we do is take the database lookup out of the constructor and put it in a load method.

- (void) load
{
    if (records) return;
    self.records=[self retrieveEmployeeRecordsFor: ident];
}

- (NSArray*) payments
{
    [self load];
    return [self.records retrievePayStubs];
    }

Now, we only load the employee records when we actually need them. If they've already been loaded, we don't do any extra work (aside from one method call). If we never need the payment records, then we don't need to do the work at all.

The class only works when it has to -- and waits 'til the last minute to do the work. It's "lazy!"