Use `+initialize` instead `+load` to instantiate iRate singleton

[rahul-malik]

Given that load methods must be evaluated before the main() method executes, I believe it would be better to instantiate the singleton instance using +initialize instead.

Is there a reason the current implementation uses load? I would be happy to put up a patch to address this

[nicklockwood]

Yes, it's because initialize is only called the first time you reference the class, and I want it to be executed even if you don't have any references to iRate in your code (zero-config mode).

[rahul-malik]

Do you think the most common usage is zero configuration though? The problem with +load is that we'll incur the pre-main cost past on every app load.

We previously had a fork of the project to handle this but I'd like to move us back on to main repository.

Would you be open to a PR that uses a conditional #define to use an +initialize method instead which could be used by consumers that know they are configuring irate?

[bvirlet]

Hello,

I also have another issue with the + load: if we want to subclass iRate to add some functionality, it's impossible to do because + load will instantiate a singleton of type iRate and not iRateSubclass. Then if we access [iRateSubclass shared].myNewProperty we will get a crash.

I feel that load is a bit dangerous in that it's not a very common pattern.

Thanks!