Big update to prettier-extension-monkeyc

flocsy🤠 said:

I think the Generate Optimized Project stopped working

You're right. Build/Build and Run/Export all still work though...

What SDK are you using? I use the latest 4.1.3 and I have actually the following in my code:

        var result as String;
        if (confFormat != null) {
            var intHr = computeIntHR(info) as String;
            result = Lang.format(confFormat, [intHr, extHr]);
        } else {
            result = extHr;
        }
        return result;

And i tried now that even with my type it works:

v2.0.12 is out which fixes that, the super-class name injection issue, and some type lookup issues.

flocsy🤠 said:

What SDK are you using?

I'm using 4.1.3 too, and I get the same result in all recent releases.

The only way I can get your code to compile is to turn off type checking... are you sure you've got it enabled? As a datapoint, in a previous post you included:

> Executing task: java -Xms1g -Dfile.encoding=UTF-8 -Dapple.awt.UIElement=true -jar /home/flocsy/.Garmin/ConnectIQ/Sdks/connectiq-sdk-lin-4.1.3-2022-05-10-b3aaee541/bin/monkeybrains.jar -o bin/X.prg -f /home/flocsy/garmin/X/monkey.jungle;/home/flocsy/garmin/X/barrels.jungle -y /home/flocsy/garmin/developer_key.der -d fenix6_sim -w <

which doesn't have a `-l` option, so has type checking disabled.

The documentation isn't 100% clear, but certainly implies that locals can't be typed:

Unlike with class instance variables, the Monkey Types system will infer the type of a local variable by tracking assignments

and none of the examples put a type on a local declaration. Also the error message I posted says pretty unambiguously that local types can *only* be inferred, not declared.

But I tested: when I added using Toybox.WatchUi; to the SAME file, then it works

Ok, there is something strange with monkeyc's behavior here. I tried removing *every* import/using of Toybox.WatchUi in my main project. Initially the typechecker caused the build to fail, but I turned it off, and the build succeeded, and my project ran. But then I tried the SimpleDataField sample project, and even with the typechecker off, the build fails without at least one import/using. But then I realized that some resources - eg menus - must pull in WatchUi, and that does seem to be whats going on. 

[Edit: I took a look at bin/internal_mir/Rez.mir, and although it *does* import various Toybox modules, the imports all happen inside the relevant Rez modules. So while Rez.Menus.WatchUI should be available in projects with menu resources, I wouldn't expect $.WatchUi to be available. So I don't think the resource theory is correct. But *something* seems to pull in WatchUi in some projects, but not others]

So without analyzing all the resources (and I'm not even sure how to figure out in a general way which resources might pull in which modules, so I'd have to just come up with an ad hoc list of rules), I can't tell whether WatchUi (or possibly other modules) was pulled in or not.

So I think I'm going to stick with the current behavior. If you have a using/import anywhere in the .mc files, that should work for all files. And I've tested, and it does. The reason your case doesn't work is that you have using Toybox.WatchUi as Ui which only makes the name Ui available in all files, not WatchUi (and I confirmed via SimpleDataField, that putting a using as in one file, or all files, did not fix the errors - although if I renamed every WatchUI to Ui, then it did fix them).

You are right I did not have the typecheck on.

You can definitely use typechecking with using, its just a little more verbose.

If you use "import Toybox.Lang;", you can then say "var foo as Number". If you use "using Toybox.Lang;" you have to say "var foo as Lang.Number" instead. But note that the latter works for both using and import. Basically import just pulls all top level type declarations from the imported module directly into the scope of the import, while using only pulls in the module itself.

Also, as discussed above, neither using, nor import needs to be in the file that refers to the used module. So a single "import" anywhere in the project takes care of importing that module into every .mc file, even ones that have their own "using" statement.

I'm actually in two minds about "import" because it can lead to some confusing cases... is it "new Menu2()" or "new WatchUi.Menu2()"; "x instanceof Menu2" or "x instanceof WatchUi.Menu2" (on the other hand, I use import exclusively in my projects, because thats what garmin recommends, and by the time I started noticing the issues I'd written a lot of code).

I was also initially worried about namespace pollution from import, since it pulls in so much. But it turns out not to be an issue, because monkeyc keeps separate lookup tables for types and values. So that

typedef Foo as Number;

module Bar {

  var Foo as String = "Foo";

  function bar(x as Foo /* x is a Number */ ) as String {

    return Foo; // returns "Foo"

  }

}

actually compiles. In fact, you can drop module Bar, and put both Foo declarations in the same module, and it still works...

Then this is for you: https://forums.garmin.com/developer/connect-iq/f/discussion/295754/type-check-level-strict-causes-cannot-find-symbol-data-on-type-null :)

I should have said using "using as".   Something like 

using Toybox.WatchUi as Ui;

jim_m_58 said:

I should have said using "using as".

Still works, you just have to say "as Ui.View", rather than "as WatchUi.View" (or just "as View" if you had used "import").

That said, I would strongly recommend against "using as" in any circumstances. Garmin seems to have decided it was a mistake.