Open rahul-malik opened 7 years ago
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).
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?
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!
Given that
load
methods must be evaluated before themain()
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