3 ms·
Namespaces don't really solve that problem, do they?. Your options are to either fork SBJson and give it its own namespace/prefix, or require SBJson as an exte
by thought_alarm 14y ago
Namespaces don't really solve that problem, do they?. Your options are to either fork SBJson and give it its own namespace/prefix, or require SBJson as an external dependency and lets your users provide their own version of the framework.
- objclxt 14y agoParse do this with their SDK, which requires Facebook Connect: all Facebook classes are prefixed "PF_".
- wsc981 14y agoI prefer if SBJSON is an external dependency, since there's less chance that I need to modify external projects my own projects make use of. The downside of course is that not all external projects might use the same version of SBJSON, so method names could have changed, could be missing, etc... So it falls to the developer to provide patches to external libraries if they use an outdated version of a library like SBJSON. Still, this is for me the preferred approach.