Big update to prettier-extension-monkeyc

markw65 said:

My issue with that is that now you're writing in a different language

This also allows you to do things that are impossible in Monkey C (like split up code blocks in a way that would normally be syntactically impossible) - that's probably not a good thing.

As noted in the previous comment, at least it's explicitly:

- a compile-time construct

- a separate "build pass"

Having said that, there's a reason most modern languages don't support this. The problem with Monkey C is that the environment is so memory-constrained that when you use any halfway "modern" features like dictionaries or classes, you waste a ton of memory.

I use that with the prettier monkeyc :)

I have constants like:
(:debug) const MOCK = true;

(:release) const MOCK = false;

and in some places I use:
if (MOCK) {do something}

FlowState said:

As a dev, I don't want to worry about stuff being inappropriately optimized away

My point was that this is an optimization I've not yet implemented (but plan to in the next release).

On the other hand, if something is inappropriately optimized away thats a bug; and yes, of course bugs are always possible. But thats true of your pre-processor, and the monkeyc compiler, and any system you use to program with.

flocsy🤠 said:

the only problem you fear is that deprecated functions will eventually be removed

I think we're mostly in agreement. My position is that 

1.  if the sdk/compiler.json says a device does not support a newer api, its safe to convert the has test to false; because worst case the device eventually gets the api, and the only consequence is that the app continues to behave as if it didn't get it. So I'll put the optimization under an option, so that developers can choose whether they want that behavior or not.
2. if we have a list of devices that are guaranteed to have a certain minimum sdk (which Garmin doesn't explicitly provide, but we can figure out, at least for certain devices) we could convert has tests to true. But now if Garmin deprecates and removes the api, the app will crash on devices that get the new firmware.

But you seem to be saying that on point 2 a careful developer could avoid any issues? I'm not sure how? I suppose I could give you the option to do the optimization, and as long as we assume Garmin goes through a "deprecated" stage before actually removing any given api, and as long as you rebuild/redeploy your app every time Garmin deprecates another api, it should be safe? [edit: Im assuming I wouldn't do the "true" optimization for any deprecated api]

If we look at AppBase.getProperty() [since: 1.0.0, and up to, not including: 4.0.0) and Properties.getValue() [since: 2.4.0) as an example then I see an overlap. So I'm pretty sure that there are a few types of devices:

1. [1.0.0 - 2.4.0): these can only use getPropery, so no need for getValue code

2. [1.0.0 - 2.4.0) union [2.4.0 - 4.0.0) (but I doublt if any of them will ever reach 4.0.0): I don't know if there are any devices like this, but if yes then these could also use the getProperty and eliminate the getValue

3. [2.4.0 - 4.0.0): these can use getValue and eliminate getProperty OR use getProperty and eliminate getValue, so the developer should decide based on features, code size, whatever is important for him.

4. [2.4.0 - 4.0.0) union [4.0.0): these can also use only getValue and eliminate getProperty

5. [4.0.0): these can only use getValue and not need getProperty

6. In theory there could be a problematic group but I doubt if there will ever be any device that started as 2.3.x (or less) and it can be upgraded to 4.0.0. If there is such device then t should either decide to remove the feature from the old or the new CIQ versions (If let's say it's an optional feature like possibility to display the body battery on a watchface) or keep both code and use has.

So if we assume that there's no device in 6 there's no need to use has :)
But I agree this can only be done manually on a feature by feature base...

I found something that IMHO can be optimized easily:

const LABEL_TOP = 0;

var color = Graphics.COLOR_BLACK;
var labelY = mLabelY + LABEL_TOP;

currently the optimized code looks like:

var pre_0 = 0;
var color = pre_0 as Toybox.Graphics.ColorValue;
var labelY = mLabelY + pre_0;

I'm pretty sure that you could easily eliminate the "+ pre_0" from the generated code.

flocsy🤠 said:

I'm pretty sure that you could easily eliminate the "+ pre_0" from the generated code

You would think.

It *is* something I'd like to do, but it requires writing a type checker. If mLabelY was a string, removing the "+ 0" would change the behavior...

Assuming mLabelY has a declared type, I could just add an option to trust declared types, and I've been thinking about that as a stop gap.

Sure it has! I use -l 3 ;)

flocsy🤠 said:

In theory there could be a problematic group but I doubt if there will ever be any device that started as 2.3.x (or less) and it can be upgraded to 4.0.0

Garmin explicitly said that only devices which released with CIQ 4 will ever have CIQ 4.

That's why we have the two-track CIQ version system AKA System 4/5/6. CIQ 3 devices stay on CIQ 3 and only CIQ 4 devices will ever have CIQ 4, but Garmin still wants to add features to both sets of devices.