clipka <nomail@nomail> wrote:
> Still, in a typical modular project it would be implemented as a library,

  I'm not sure if we have the same concept of what "library" means.

  I don't see "module" and "library" being in any way mutually exclusive
concepts. They do not even talk about the same thing. A module is a
programming design/paradigm device. A library is simply a reusable piece
of code (usually residing in its own file or files).

> providing (A) a classic data structure to hold a string, and (B) classic
> routines to operate on them.> There may be talk about "instantiating" with
> regard to the data structure, but not with regard to the module as a whole,
> which might contain additional data structures such as a dedicated heap for the
> strings to live in.

  It sounds to me like you are talking more about syntax than design questions.

  Of course modules can have static data (data which is not tied to an
instance of the module, and thus shared by all the instances) and dynamic
data (data which is stored in each instance and is specific to it, also
called the "state" of the object).

> Most modular projects use a much too heavyweight concept of a module to
> instantiate whole modules for such small stuff as a single string.

  I don't understand how you instantiate a "heavyweight concept of a module".
It sounds to me like you were arguing that if a module contains a thousand
member functions, "instantiating" that module would mean replicating all
those functions for each instance.

  I don't even understand why a modular programming language would even
*support* that, much less want to do it. What use would there be in
replicating a function many times, when the whole idea of a function
as a subroutine is precisely that you *don't* have to replicate the code,
but instead you can call the *same* function/subroutine from different parts
of the code.

  Of course when you instantiate a module, you instantiate an object
containing the dynamic member variables of the module (ie. its state).
After that, whether you just call free functions, giving them the object
as parameter, or member functions through the object, is simply a question
of syntax (and not of implementation), and sometimes of design.

  That is what happens in Modula, C++ and most other modular/OO languages.
Why would any language want to do it differently?

> And those that do have a lightweight enough concept of a module typically fall
> into the full-fledged OOP category anyway.

  Modula doesn't.

> So no, in typical modular projects, modules are not instantiated. Unless the
> system gets so big that it may need to live on multiple machines - in that
> case, yes, modules are indeed very frequently instantiated: One instance per
> machine.

  That's not how I understand modules, nor have I ever heard such a thing.

-- 
                                                          - Warp

Post a reply to this message