Acknowledged
4 months ago

deprecation warnings should not be raised when there's no alternative

I know this issue has been raised before but with the new app I'm writing I'm trying to be a good citizen and to avoid all compiler warnings, so as the issue bothers me I'm raising it again. :)

It's simply impossible (I don't consider providing a command line parameter option to ignore warnings a valid option) to create a warning free app if you also want to support "older" devices

in particular in this specific app the warnings I'm seeing are:

WARNING: device name: soucefile: '$.Toybox.ActivityRecording.SPORT_TRAINING' is deprecated.

WARNING: device name: soucefile: '$.Toybox.Application.AppBase.getProperty' is deprecated.

WARNING: device name: sourcefile: '$.Toybox.Application.AppBase.setProperty' is deprecated.

Is it really not possible to make this warning context aware? Surely this should not be too hard? 

Eg if you are building for a fenix 3 you know that:

- you can not use the Toybox.Activity.Sport types as they are only available as of api 3.2.0 and that you HAVE to reside to ActivityRecording types

- you can not use Storage.getValue or Properties.getValue as they are only available as of api 2.4.0 and that you HAVE to reside to getProperty

 TL/DR make the deprecation warning context aware and only raise it when the preferred alternative is available to use

peterdedecker
Parents
  • 4 months ago

    This isn't system level connected.

    This is at build time you throw a warning or you don't. It's something that can be handled at the sdk side and more importantly there's no device side coding change required.

Comment
  • 4 months ago

    This isn't system level connected.

    This is at build time you throw a warning or you don't. It's something that can be handled at the sdk side and more importantly there's no device side coding change required.

Children
No Data