Conversation
# By Sam Duke # Via Sam Duke (1) and samskiter (1) * hotfix/docs: Update README.md Update README.md
* release/v0.2: bumped to version 0.2 added personal email Correcting the Podspec, removing NSLogs and replacing them with assertions and/or boolean success returns on adding reference schemas. Updated Podspec Get rid of the goto Reorganizing the project for cleaner CocoaPods integration Added travis.yml for Travis build status. Added a CocoaPods pod spec -- email omitted Added extra assurance that the test suite is executing okay. Initializing some uninitialized variables. Extracting the one/true false/zero checks for uniqueItems and refactoring them. Both of these changes are in order to resolve a condition where the fudgeFactor calculation was falsified -- falseFound was already false (due to an uninitialized variable and an unreachable else-condition). With Xcode 5.1 the unit tests are still passing now. With an earlier version of this commit, Sam noted that the tests were failing, though I'm not sure if it's a variation due to differences in compiler versions (that would be scary). Hopefully it was just a matter of an incomplete commit on my part. Regardless, "it works fine for me" :-) Creating an NSNumberFormatter is one of the most expensive single-line methods in the Foundation framework (along with NSDateFormatter). If I recall correctly, each time you create one, it allocates 100+KB of memory and takes several milliseconds to complete. If you ever create one, make sure that you *only* create one, and then reuse it. But preferably, just don't create one if it's not needed (as in this case). Use obj-c BOOL constants instead of C. Rename uppercase variables to camelCase. Added a variable (schemaItem = schema[keyword]) to get more reuse out of the schema dictionary's objectForKey method. addRefSchema methods return boolean indicating success/failure. Fixed up the KiteValidationPair to have a good hash and description. It also uses auto-synthesized ivars Renamed the test class/file and the Pair class/files. Fixed some compiler warnings (Xcode 5.1) and annotated FIXME's for the static analyzer's discovery of garbage values in the uniqueItems fudgeFactor calculating conditions.
* release/v0.2.1: bump version to 0.2.1 Update to latest test suite and fix unicode length failures. Update README.md Update README.md Update README.md
* release/v0.2.2: bump to v0.2.2 switched on and fixed a bunch of warnings fixes for stricter warnings
Conflicts: Sources/KiteJSONValidator.h Sources/KiteJSONValidator.m
|
@samskiter this patch is going to break backward compatibility. For the existing library users it may be like Still, I agree that NSError should be returned by the affected method. // AS IS
-(BOOL)validateJSONData:(NSData*)jsonData withSchemaData:(NSData*)schemaData;
// from the patch
-(NSError*)validateJSONData:(NSData*)jsonData withSchemaData:(NSData*)schemaData;
// My proposal
// follows Cocoa conventions
-(BOOL)validateJSONData:(NSData*)jsonData
withSchemaData:(NSData*)schemaData
error:(NSError**)outError; |
|
@dodikk that's a great catch! thank you. My head is in Java mode at the minute and I forgot about the auto cast. also, this is actually the way i prefer to return errors if any - more consistent with apple's APIs and other libraries @nut-code-monkey sorry for another delay on this PR. |
|
@samskiter , I think, these days I'll finally get a chance (in terms of time) to add your validator to my project. Eventually, I'll adopt these changes and remaster the API in the Cocoa way so that you'll get a patch from me. P.S. @samskiter , I guess, this one is no longer relevant and can be closed. #9 |
|
@samskiter spent some of my leisure time trying to make the API follow the cocoa style dodikk@7db8dae I can't afford spending so much time copy-pasting the |
|
It would be a lot easier if I could use Such policy makes sense since it will be a lot harder to ignore validation errors. @samskiter , what do you think? |
|
Hi @dodikk thanks very much for your efforts. this is on my TODO list to sort out properly. It does look a little smelly that we have to have a lot of checks agains NULL (this should probably be |
That's how out parameters are done in "plain old C". And yes, apple allows NULL errors in their own API.
No, it should not. |
3 participants
Merge branch 'master' into develop
NSError as a result of validation/schema adding