You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
rahul-malik
changed the title
Use initialize vs load to instantiate iRate singleton
Use +initialize instead +load to instantiate iRate singleton
Jun 24, 2017
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?
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.
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 thisThe text was updated successfully, but these errors were encountered: