Modularity

new topic     » topic index » view thread      » older message » newer message

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.

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu