Under Review
over 1 year ago

feature request: allow to spedify type checking level in the monkey.jungle file

I dislike that typechecking has to be enabled/disabled globally 

- For my existing projects I really don't want to (/I won't) go back and fix thousands of type check warnings

- If I start a new project I might use type checking

I propose to add a new keyword to the monkey.jungle file which adds a new keyword:

typechecking = [none | gradual | informative | strict]

Having this would enable you to choose on a per project basis if you want type checking on or not for that project.

  • I wasn't suggesting that the extension doesn't know where the setting came from, I was suggesting that if you set a non-default type check level in the user or workspace extension settings, the extension *unconditionally* passes this setting to the compiler in the form of a command line argument, at which point it becomes indistinguishable from a user-supplied type check level (also in the form of a command line argument)..

    Given that we probably want a user-supplied command-line arg to take precedence over monkey.jungle, I see two ways around this:

    - the extension should be super smart and avoid passing the the type check extension setting to the command line if it also exists in monkey.jungle (I don't like this option, because it might seem random to the developer)

    - to use your idea, the extension should use a different (and perhaps undocumented) command line argument for a type check level that came from extension settings, so it can be treated with lower priority than any type check level in monkey.jungle

    Obviously both of these approaches have pros and cons. The status quo has the advantage of simplicity, even if it doesn't always do exactly what you want.

    Another alternative is to use the per-workspace or per-folder (project) Monkey C extension settings to override the type check level for projects, as opposed to the monkey.jungle route. The only disadvantage here is that it won't work for command-line builds. (Then again if you build exclusively from the command line, then the VS Code extension settings objection doesn't matter in the first place.)

    > I love the garmin sdk, but this is (yet) another case where the implementation falls short.

    Do you really lol?

  • I love the garmin sdk, but this is (yet) another case where the implementation falls short.

    It should be Command Line settings > Monkey jungle > Extension settings, not Command Line settings > Extension settings > Monkey jungle. Ignoring what's in the monkey.jungle when the setting is anything other than default is just taking the easy way out 

    This basically makes the extension settings useless (to me). I would like to set type checking off at extension setting, and set it on for new projects in my monkey.jungle.

    There are 2 ways to implement it properly (from an end user point of view):

    - Either they have to make the extension smarter to know where the setting is originating from (I havent looked into vscode extensions, but I can't believe you can not query what the dropdown setting is or what the command line arguments are)

    - If this really can not be queried, a way out would be to add an extra parameter set for the type level extension settings so it can be differentiated in the parameters whether it was a dropdown setting or a command line setting by the user.

  • yes, but not implemented the way i wanted it to see implemented, the setting only takes effect when the setting is set at default level in vs code settings.

    I still believe the monkey jungle level should take precedence over what the vs code settings specifiy

    It probably should, but I can see why it doesn't. The VS code settings are applied by passing a command line argument to the compiler.Typically, command line args take precedence over configuration files. (Yes, I know that VS code settings are also part of a configuration file.)

    The problem is that the compiler has no way of distinguishing between a type check level that was passed in from VS Code extension settings, and a type check level that was specified manually on the command line (or via the manual command line arguments option in the extension settings.)

    The reason it works when the setting is at the default level in the VS Code settings is because that causes the extension to omit the command linen arg completely when building the compiler command line.

  • yes, but not implemented the way i wanted it to see implemented, the setting only takes effect when the setting is set at default level in vs code settings.

    I still believe the monkey jungle level should take precedence over what the vs code settings specifiy

  • This was implemented in 4.1.7:

    project.typecheck = 3