Correct syntax to reference a class function inside a class as a module

@Robin, I (still) try to understand what the context is when you use the term 'deployed'. In Espruino that term is not used. But from reading through your post, I looks to me that with 'deployed' you want to say that it is a module and is pulled with require(....

Is that how you would define your term 'deployed (as a module)' ?

Within Espruino the term 'inline testing of module code is a known term and way to develop a module together with the application code in the same file (in the Espruino IDE. Once done with the development, the module part is put into modules folder (or where ever you can pull it with require(.... You use the term "monolithic file". I can understand that you look at some things from a different angle and names you are use to... but that makes it difficult to grok the context your question comes from or comment is about (btw, files are always monolithic from the point of a file (may be not from a point of operating / disk operating system that stores the file in some kind of blocks, contiguous or scattered in the space of the storage).

So far the inline testing - as suggested in https://www.espruino.com/Writing+Modules for https://www.espruino.com/Modules- is something very brittle, because it uses the same name space... and that usually creates undesired side effects, constraints application in name choices, and worst, can lead to interference (breaking side effects).

I started to use (also) a different approach to get the core issue - namespace problem - out of the way by loading the module cache directly, as described in the conversation about Module development - and shows explicitly in post #3.

Inpost #3 you can see the module cache primed with the module source code and the module then retrieved by require(.... No omissions or additions and especially no name conflicts, undesired dependency nor forced dependency between application and module, commenting and uncommenting of different things at different times - all bad things... For example: now you can name the things in the module code the way you want and chose the name you want in the application code without worrying that there is a disconnect or conflict. Furthermore, it is absolutely clear what goes where: you just take the source and put it into a file into modules folder with the desired module name.

In post #8, this technique uses a newer feature of Espruino which allows to store modules as functions in the modules cache. Initially, the cache loading could only happen by providing source code, which is a test string. At a later time, @Gordon introduced the storing as a function, which makes it equally simple to have the modules demarcation within the application when doing 'inline development and testing'.

What ever you do in the module source - text string - post #3, lines 5 thru 33 - OR function body - post #8, lines 5 thru 42 in final code - is not visible to the application code what so ever. require(... exposes only what you want to let be seen by the application with the name to be used outside of the module... can be same or different of the name in the module. With class names, you can give a three different names, one each class name in the module, one for the module, and class name in the application... Usually, one strives for sanity reasons to give the module and the class the same name (especially when there is a 1-to-1 relationship between module and class: each class makes a module.

Furthermore, it seems to me that you see a class is different whether the class is defined inline or in module. There is no difference, because module is not tackling the structuring of software in classes, tackles the issue of separating source code into files, even though latter can be used to achieve former in order to enable reuse of classes without having to copy-paste source code... ;-)

I suggest to take a deep look into Module development. I think it could help answering some of your questions and to develop your concepts even further.

Btw,

1. Javascript allows only one constructor... you can the no to many parameter option... - but only one constructor. If you want a mix, you allow to pass a single object, and in the constructor you look what properties are in the passed object and use these, for the others you use defaults accessible from or hardcoded within the constructor.

2. The lines 39 and 43 in the code in post #2 collide logically...

   • Line 39 creates a stop watch instance and starts it right away (with the "auto" parm). That happens when the code is uploaded (and save will then save its state at the time of saving... some time into the ticking...)
     
   • Line 43 uses the same instance and starts it again... Nothing may break that, but I'm not sure that is the intention... it would be for sure not mine. What could be done is use in line 39 not the "auto" nor any other parameter that gets the (code) bomb ticking... eeeehh, I meant stopwatch...