Leveraging excluding-annotations further more for CIQ-newbies

TL;DR
apparently 'has' could be applied to user's own code too,

therefore combining excluding-annotations with 'has' on one's own code stretches its usefulness further

to e.g. provide user-apps-level granularity.

And as I have been under the impression 'has' could only be used/applied-to framework code (vs one's own code),

I am sharing this bit for other newbies, who might have been under that false impression too:

full details:

While old-news for the awesome jim_m_58, travis.vitek and the rest of the big calibers,
I am sharing a means I am using to achieve a  user-apps-level granularity for the sake of code-reuse:

given:
I have 2 WFs - one analog and one digital -
and they share a lot of code/functionalities in common, e.g. loading/applying settings, themes, calc and drawing time-marks, sun-events, etc.
As such, (at the price of additional memory) the 2 code-bases have been structured in a modular way,
with the common code living in e.g. source/common classes/modules, and WF-specific code in source/ classes/modules.
This way:

(1) creating a new WF will be much less painful next time (as all common functionalities have been untangled already)

(2) fixing bugs/enhancing/replacing a common functionality is applied once and the file is simply copied over to the other code-base

p.s. code-reuse is leveraged accoss the whole codebase, such that e.g. the very same code runs on VA3m/240x240 to D2-Air/390x390.

problem:
The class responsible for setting/theme/etc loading/applying is identical in digital/analog WFs code-bases but for one exception - time-font:
while the analog-WF utilizes hands (and not from a font file) -
the digital-WF utilizes numeric chars from a font file, and further - its size is customizable via settings;
and the end-result of that is that digital-WF-specific-code needs to be invoked from within this common-to-both-code-bases class.

solution:
preferring to keep that time-font field + its related digital-WF-specific-code in that class (next to all other fonts),
and yet resolve the compiler errors (analog WF build fails as it does not have the digital-WF-specific-code mentioned above)
the following approach has been applied, and it seems to work:

/**
 * analog  WF monkey.jungle: base.excludeAnnotations = base;excludeFromAnalogWf
 * digital WF monkey.jungle: base.excludeAnnotations = base
 */


class SomeCommonFuncClass { // agnostic-WF-type class responsible for common func of setting/theme/etc loading/applying

    (:excludeFromAnalogWf)  // so analog-WF does not have this field
    var m_fontTime = null;



    function initialize(p_dc) {
        ... // common code

        if (self has :m_fontTime) {  // so analog-WF does not waste memory on this font
            m_fontTime = Toybox.WatchUi.loadResource(Rez.Fonts...);
        }

        ...
    }



    function onSettingsChanged()
        ... // common code

        if (self has :m_fontTime) {  // so analog-WF does not invoke this digital-WF-specific-code
            onSettingsChanged_timeFontSize();
        }

        ...
    }



    (:excludeFromAnalogWf)  // so analog-WF does not contain this digital-WF-specific-code (==smaller memory footprint), which analog-WF does not even have (==build will not break)
    function onSettingsChanged_timeFontSize() {
        ... // invoke digital-WF-specific-code which does not exist in analog-WF code-base
    }