Re: Experimental "peer to peer" modular programming concept
- Posted by Spock May 14, 2015
- 1647 views
I find that large programs have lots of GUI code mixed with data processing, and i have a difficult time making it modular, because there is always a higher layer that has to control all the modules by calling public/export routines. That higher layer grows and grows until it is 1000-2000 lines of code in a single file and i get so lost, i can't even finish adding all my planned features. This publish-subscribe design doesn't require a higher level to control modules, but instead a lower-level library that all modules include and control. Then, many small include files can handle specific parts of the GUI and/or data processing of a large program.
Your situation (work + GUI) is probably similar to mine. Yet what I end up with in my programs is lots of include files each handling some low-level aspect. The problem is then compounded by having *additional* include files to manage the behaviour of groups of those files. The reason for this difference could be that I tend to refactor progams in order to compartmentalise unique/logical functionalities, eg, all vessels are listed in just one module, all customers are managed similarly in another module, all invoices are handled in another, etc.. the job of these modules is just to respond appropriately when interrogated by others. On top of that there are specific modules to link the GUI + behaviour aspects of the program.
I had started doing this refactoring with the GUI but got a bit sidetracked. The result would (will) have been having a separate module manage each control class. Does Redy have this structure already? I ain't looked recently.. One prime candidate for GUI refactoring is the list of constants. ATM I have a single list of many constants but very often a routine might only need access to a very specific group. I'd prefer to locate those constants inside the calling routine. But if those constants are ever needed elsewhere I have a problem. The solution could be a change to the language that might allow this:
function myfunc() include constants.ew : mysmallgroup .. end function
In this theoretical case only the constants declared in mysmallgroup (which is a just a small section inside constants.ew) would be visible to the routine. Admittedly it is a bit revolutionary for Euphoria but it's the direction I would like to take a language.
The uni-directional behaviour of include could also be improved but mutually including modules are already possible in Euphoria (to my knowledge). What makes this a bit dangerous is how module initialising is done when there are dependencies. These days I tend to have a specific init() routine in each module that is called from a higher level after the GUI entry point.
Your idea of using publish-subscribe would certainly be useful in my programs, eg, when an event affecting many modules only needs to be transmitted as a message once rather than many times. Other than that I'm not sure it would necessarily improve other things. In general, I structure each module so that all handler routines are clustered at the end of the file and their job is solely to interpret the Windows messages as behaviours, ie, there is little or no actual work done by the message handlers - they simply pass that on to the main program.
Spock
