Ah it' short-circuit evaluation: http://en.wikipedia.org/wiki/Short-circuit_evaluation
On Thu, Apr 26, 2012 at 2:41 PM, Shazron <[email protected]> wrote: > I'm attempting to fix: https://issues.apache.org/jira/browse/CB-567 > > These lines: > https://github.com/apache/incubator-cordova-js/blob/master/lib/common/plugin/ContactField.js#L11-12 > > The problem is, in iOS some users are passing in the type and value > properties as numbers but not strings. These are passed in to Obj-C as > the same type (NSNumber) and are passed directly to the underlying > AddressBook framework untouched (it will require code to filter and > test for these props, and I'd rather not touch working code at this > point, and it's a lot of code if you look at it) but it will throw an > exception because it didn't expect a NSNumber. I know, it's really a > bug in their implementation but I'm asking for suggestions on how best > to fix this. > > I'm thinking that I could just .toString() the properties and this > does solve the problem, but since this is common code I'm wondering > what the side effects are for the other platforms. Or should we punt > this and just say "don't do that!" for the problem? > > As an aside, this is what I propose for the fix for example: > > this.type = (type && type.toString()) || null; > > It seems to work from my tests but I'm not exactly sure why (type && > type.toString()) evaluates to a String (where it will evaluate that > expression when type is anything non-null) - something for wtfjs?
