supress specific warnings?

I was scimming through the documentation but couldn't find the answer.

Is there a way to supress specific warnings? I get a lot of "$.Toybox.Application.AppBase.getProperty' is deprecated." (I think I must use these functions if I write an app for fr230?). Can I supress this warning but still be able to see other warnings that occur?

project.typecheck = 0 supresses all warnings?

FlowState over 2 years ago

fuselage said:
Is there a way to supress specific warnings

Unfortunately not.

fuselage said:
project.typecheck = 0 supresses all warnings?

Strictly speaking, that just disables type checking completely, which does happen to also suppress the deprecated function warnings (I guess the type checker also checks for deprecated functions). (But you may still see other warnings, such as the warnings about supported languages or launcher icons.)

You can suppress a *true* type check error/warning using the annotation (:typecheck(false)) on a *symbol* (like a function). Unfortunately, this does not suppress the warnings about deprecated functions.

fuselage over 2 years ago in reply to FlowState

Thanks for the answer. Yes I assumed that typecheck = 0 supressed everything, and that's not what I wanted. I would still like to receive warnings for other things I might do wrong, so I'll just scroll through the list and try to ignore the 'deprecated' lines.

peterdedecker over 2 years ago in reply to fuselage

fuselage said:
Yes I assumed that typecheck = 0 supressed everything, and that's not what I wanted. I would still like to receive warnings for other things I might do wrong

you will still get other warnings, you just disabled typechecking, you did not disable warnings.

I've spawned some ideas in the other bug thread to resolve the deprecated issue with getProperty, another idea i just had could be to introduce Properties.get/setvalue and Storage.get/setvalue for old devices and then replace that at the level of the prg assembler (old devices using the old instructions, new ciq4+ devices the new instructions). Replacing it at assembly level means that there are no device firmware change requirements. No forced wrappers on ciq developers, no frustration for the ciq team....

FlowState over 2 years ago in reply to peterdedecker

peterdedecker said:
you will still get other warnings, you just disabled typechecking, you did not disable warnings.

Yes, but it's strange that disabling type checking disables the deprecation warnings, but using the :typecheck(false) annotation does not disable the deprecation warnings.

I get that the former is true because the type checker handles the deprecation checks, but the latter behavior seems a tad inconsistent.

Monkey C really needs a compiler directive to ignore warnings/errors for the next or current line.

peterdedecker said:
I've spawned some ideas in the other bug thread to resolve the deprecated issue with getProperty, another idea i just had could be to introduce Properties.get/setvalue and Storage.get/setvalue for old devices and then replace that at the level of the prg assembler (old devices using the old instructions, new ciq4+ devices the new instructions). Replacing it at assembly level means that there are no device firmware change requirements. No forced wrappers on ciq developers, no frustration for the ciq team....

As I asked in the bug thread, if the semantics/behavior of getProperty() are different from the Storage API (as you said elsewhere), would it be appropriate for the former to be silently replaced with the latter?

peterdedecker over 2 years ago in reply to FlowState

I did see that comment

If it was up to me I'd leave all api's in place but apparently the team gets frustrated to having to drag the old one along.

IF it HAS to be discontinued instead of just being deprecated then I think it's way better to have a form of backward compatibilty, Just removing a popular api is far from ok in my mind,(even if it only affects new devices as it breaks inheritance patterns).

The solution that's proposed to use excludedannotations or to use has checks I never thought to be a good solution. (Not back when the storage methods were refactored, not now)

I think semantics are very similar no? The return type of the old method is object and from the new types it's more specific, but for example looking at setvalue in practice i don't see anything else used but String and Number

Behavior and performance might differ yes, but if it does it will only break a small percentage of apps and not all of them.