Modularity
- Posted by ken mortenson <kenneth_john at ?ahoo.co?> May 28, 2008
- 605 views
Before beating me up on any particular point, please read the whole thing. Please forgive me for beating a dead horse but it nags me that there is such disagreement on this topic. Some have taken issue when I claim that INCLUDE is a less than modular methodology and therefore Euphoria is a less than modular language. I believe this to be self evident, but obviously I need to make the case in an understandable way. I don't know how well I can do that, but I'm going to take another shot at it. My definition of modularity is a bit like legos, parts that fit together. A module, hides it's internals and exposes an interface. I assume we agree. Suppose I have a library consisting of multiple files and I use this library by including a main library file in one of my projects files which may or may not be my main program file. This main library file includes other files which may include others and so on. Namespaces can be used to hide globals of included files if I understand the discussion I've read so far in the other threads. Library globals that are not hidden by namespaces are therefore part of the interface of the library. Therefore (for this particular scenario) all files of the library have to considered as one module. Files that have no visible globals are still considered to be part of the one module as they are part of the modules hidden internal structure. This is my first disconnect. While technically this is modularity, it is very course grained. My concept of modularity is much more fine grained than this. So already we have reached a point where Euphoria is less fine grain than my primary language VB6 where every file is a module (either a standard module, a class, or a form.) However, there is no reason why a third party library could not have several different files that may be include in your project as separate module which would be a finer grain of modularity. So what's my hangup? I suppose it's just that for the last decade I've been used to modules being physically separate files. But even these separate files may call each other and therefore technically are part of the internals of the module. It's not the way I usually think about it, but it is comparable. So actually, even these separate physical files could be thought of as less than modular if there is a level of coupling between files which is often the case. I'm coming around folks. Let's see if I can make it to the home stretch... Another sticking point. Modules as I'm used to are physical files that can be called but do not expose the interface of any file they call (not without an explicit public function but that still keeps the files it calls hidden.) Euphoria could do the same thing, but in practice I'm thinking since it's not limited to this behavior it doesn't (anything not restricted tends to be exploited.) I'd have to give Euphoria a half point off for this, but it's not really a big deal. So I guess my conclusion is that there really is no reason not to consider Euphoria a potentially fine grained modular language. I've got a thick skull so it may take a while for this concept to sink in. Thank you for playing. Collect your prizes at the door.