• State Not Answered
  • Replies 4 replies
  • Subscribers 19 subscribers
  • Views 333 views
  • Users 0 members are here
Options
Related

Confusing definition of LightNetwork.getBikeLights().

Dirkjan2016
over 1 year ago

In API documentation (and also in SDK) it is:

getBikeLights() as Lang.Array<AntPlus.LightNetworkState> or Null

But it returns an Array of BikeLight.

When type check level is set to strict you need to do a lot of workaround code to handle this.

But I could be wrong.

Like:

mBikeLights = mLightNetwork.getBikeLights();
 var bikeLights = mBikeLights as Array;
for (var i = 0; i < bikeLights.size(); i++) {
          var light = bikeLights[i] as BikeLight?;

See: https://github.com/djs2014/settled

  • 0 over 1 year ago

    I would call those 13 characters "a LOL of workaround code". It looks like a bug in the documentation, and don't worry, that casting is a compile time only thing, the compiled bytecode is the same. You can report this in the bugs forum, hopefully Garmin can fix it easily (if it's really just the documentation)

  • 0 over 1 year ago in reply to flocsy🤠
    flocsy🤠 said:
    don't worry, that casting is a compile time only thing, the compiled bytecode is the same

    In this case, maybe not, assuming the block-scoped light variable was introduced solely to make the cast possible (and that this workaround is necessary for the cast). That's also assuming that either optimization is disabled or that light wouldn't be optimized away.

    flocsy🤠 said:
    just the documentation

    As with the weather bug where temperature-related fields were typed in the SDK (and documented) to be Number but in reality they were Number or Float, it's not "just" a documentation problem if the types for API fields and/or functions in the SDK are wrong. It's an error in the CIQ API and it undermines the whole point of the type checker by giving you a false sense of security.

    Assumption: "My code compiles with strict type checking enabled, therefore run-time type errors are impossible."

    Reality: "My code is crashing with a run-time type error. I feel so lied to!"

    I would go as far as to say that any API-related code which *requires* you to do a cast is problematic, and I think casts (*) are dangerous and should be avoided whenever possible (including in languages such as typescript.) I'm still very disappointed that the Monkey Types designers chose use the same syntax ("as") for both type declarations (makes your code safer) and type casts (dangerous, makes your code more fragile).

    (* ofc I'm only referring to casts in a statically type checked language such as monkey c, typescript or python. The situation for C, C++,  and Java -- for example -- is a lot more complex.)

    If an API function was documented to accept the wrong number/type of arguments, nobody would say "it's just a documentation error". (an extreme form of this problem is the issue where the version of the makeWebRequest callback which accepts an additional context arg is unusable, since you can't guarantee that the version of the callback which takes fewer args won't be called, leading to a runtime error.)

    I would def report this.