Darren New <dne### [at] sanrrcom> wrote:
> >   Still related to ease of use rather than reusability.

> You have to spend less time tracking what's inside the class if the 
> memory management (well, really, resource management) is done 
> "properly". You don't have to worry if (for example) object A you passed 
> to object B to initialize B is still being referenced after you've 
> finished with B. E.g., if you pass a bitmap to a window for drawing, 
> when can you throw away the bitmap? Does the window object copy the 
> bitmap or just hold a reference to it? If you actually have to say, then 
> you've exposed implementation details of your class, and of the bitmap 
> class (which now might need a "clone me" operator). This gets even more 
> obvious when you start having things like a open-file-handle used by a 
> certificate used by an encryption-in-progress used by an SSL-link used 
> by a socket used by an HTTPS connection used by a network-rpc used by 
> .... When is it safe to close the file handle if you're the one that 
> opened it?

  I still see only thing related to ease of use rather than reusability.

> This is kind of exactly the sort of thing you complain about with 
> finalizers versus destructors all the time. I'm kind of surprised you're 
> now disagreeing with me.

  I'm only disagreeing with your definition of "reusability", which still
sounds to me like "easy to use".

> >> The idea of modules was around long before OOP. :-)
> >   Didn't you read what I wrote in parentheses?

> Of course. But if it's modules that make something reusable and not 
> objects, then that's just supporting my point.

  In fact, OOP brings modules on steroids, and offers tools which a pure
modular language doesn't. These tools can also be used for reusability.

> >> They were called "libraries".
> > 
> >   When I say "module" I'm referring to a much more concrete entity than
> > a generic "library". I'm talking about modules as per the modular programming
> > paradigm.

> I know.  In practice, a "library" is also a "module" in many ways, 
> especially if designed to be reusable.  By which I mean a library 
> designed to do one specific thing, such as parse XML or so. Yes?

  An XML parser is actually a good example of a library which benefits
(from a reusability point of view) from the OOP paradigm. That doesn't
mean a good and reusable XML parser couldn't be implemented with other
paradigms, it means that the OOP paradigm is very well suitable for it
(often even better than many other paradigms).

  I can think of two different ways of implementing an XML parser library:

1) The parser library is initialized and told to parse some XML file.
   After that, the calling code traverses through the elements in the XML
   file by asking these elements from the library one at a time.

   Where does OOP kick in? Well, one very natural way of implementing this
   "XML element" which the library returns is for it to be an object.
   After all, "XML element" is a concept, something very suitable to be
   described as a class.

2) The calling code implements a virtual callback class/interface defined
   by the library, gives itself to the library, and then tells it to
   parse the XML file. The library then passes all the parsed elements
   to the calling code by using this callback interface.

   The callback class/interface is pure OOP, so there's no need to argument
   that any further.

  Especially in the second case the OOP aspect helps reimplementing the
code which receives the XML elements on a per-program basis. This is
reusability at its best.

> >   Some people call C header+source file pairs "modules", but that's not
> > the kind of module I'm talking about. That has little to do with the modular
> > programming paradigm.

> Hmmmm... I suspect you'd have to describe to me what you think "modular 
> programing paradigm" means before we could talk meaningfully about that.

  Should suffice to say that modules should be instantiable.

  (With that I don't mean that *all* modules *must* be instantiable.
What I mean is that the module should support instantiation unless it
has been specifically forbidden.)

-- 
                                                          - Warp

Post a reply to this message