Bug? Should a local enum take precedence over a module?

This seems like the inverse of the bug you reported where the compiler incorrectly thinks that Activity.Sport is ambiguous because both Activity and ActivityRecording are imported, and both modules contain Sport.

It seems that the compiler wants [Module].[Symbol] to be synonymous with [Symbol] and vice versa, even in cases where it doesn't make any sense.

The question is: do I interpret the Monkey C language correctly => I'll open a bug
Or I'm wrong => please explain

I think that if seems like a bug to you, you should open one. I would.

Even if it's intended behaviour, it seems unintuitive to me. Why should the lookup scope rules be different for classes vs other symbols? Maybe it's an oversight / optimization where Garmin doesn't expect you to use the name of a class for a different kind of symbol.

If you open a bug report, at least Garmin could explain the actual reason for this.

Another definition of bug (beyond whether the behaviour "makes sense" or is intended) could be whether the bug causes harm.

If you didn't have "action = Menu" in your code, would compilation still have failed with an error? Or would it have succeeded without warning or error, assuming that the compiler doesn't try to type-check switch case values.

If this behaviour makes it possible to unknowingly write and ship bad code, I would call it a bug (or a bad design).

To answer my own question, with the default type-check level, only "action = Menu" causes an error; there's no other warnings or errors. Without "action = Menu", it's possible that the unintended behaviour would never be noticed.

To me, reusing the same name is kind of a poor coding practice.  It's not just what the compiler likes, it's the overall;; readability of the code.

In the original post, I'd never use "Menu" for an enum. Maybe something like eSelect, eBack, eMenu

The interesting is that, as with the other bug, this only happens if you use "import" instead of "using". If you change "import" to "using" (which ofc is not recommended), the problem goes away.

So it's def related to the behaviour of import that brings all the class names into the namespace.

[https://developer.garmin.com/connect-iq/monkey-c/objects-and-memory/]

Import and Using Statements

You can bring a module into your scoping level with the import keyword. When you use import it will bring the module suffix and all classes in the module into the type namespace. This allows classes in a module to be accessed without the module suffix, making for easier typing. Function invocations still require the module suffix to be accessed.

jim_m_58 said:

To me, reusing the same name is kind of a poor coding practice.

Yes, I agree. Furthermore, the enum naming style in the OP doesn't match what Garmin uses for its own enums in CIQ.

I would probably use the "Monkey C style" for enum values (all uppercase with underscores), which is also seen in a few other languages (js, C, Java).

e.g. ACTION_SELECT, ACTION_BACK, ACTION_MENU or SELECT, BACK, MENU

Using title case for enum values (e.g. True, False, FileNotFound) seems to be more of a C# thing.

All your workarounds are... just that. That doesn't fix the bug, just masks it. In fact bad coding is a feature, it helps finding compiler bugs :) And no matter what you say, my coding is not bad, it's just different. I like Menu, and not eMenu or MENU (though the latter is something I might consider, but again, it would just mask the bug, which I don't need to as adding self.Menu also works around the bug)

I didn't say your coding was bad, I said that your enum convention was different. Different than Monkey C, different than many other programming languages, but similar to C#. This isn't C# though. I also said that I agree that using the exact same name as a standard CIQ class might be confusing, but ofc it's up to you what you want to name your stuff. I will point out that not using title case for enums would avoid the problem altogether.

I never said that I think you should use "using" instead of "import", I was pointing out what the root cause might be and mentioning that it seems to be the same problem as the other bug that was mentioned. Information like that might be useful to Garmin, and it's interesting to me (maybe not to you) because I like to understand why things work (and why they don't).

I also said that I agree it's a bug.

I don't know if it's a good idea to use Menu as an enum name in a gist that you share with others (in the other thread), when you *know* there's a Garmin bug that requires a workaround (which you have also added to your code).

If you don't like other people suggesting workarounds to you, why would you share code that has a workaround in it? Workarounds are ok when you use them, not when others talk about them, even just to figure out why a problem is happening? Maybe it's an F U to Garmin to tell them that they have an annoying bug? Except ofc Garmin doesn't care, it's only people who use your code who will be affected (and who won't know or understand why you had to use "self.Menu" in your gist.)

I also never claimed that anything I said fixes the bug, that's what the bug report is for.

I was trying to help investigate and discuss the problem, but maybe that was a mistake.