incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: ContactField
Date Thu, 26 Apr 2012 21:48:23 GMT
Ah it' short-circuit evaluation:
http://en.wikipedia.org/wiki/Short-circuit_evaluation

On Thu, Apr 26, 2012 at 2:41 PM, Shazron <shazron@gmail.com> 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?

Mime
View raw message