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

Warp wrote:
>   I still see only thing related to ease of use rather than reusability.

Ease of reusability, then. ;-)

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

I think what I'm stressing is that you can not only use it in different 
programs, but with different types of data that you might not have 
anticipated when you wrote the program in the first place. That's where 
the ability to let objects manage their own lifetime (i.e., 
encapsulation of the resource management) comes into it.

> 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.

That's called the DOM. (Document Object Model.)  Or, rather, the 
standard object interface for it is called DOM. Note that while you do 
indeed "reuse" the library when working with it, the tendency is to not 
actually ever write subclasses for the DOM objects, so generally it's 
neither more nor less "reusable" than a procedural library. It's perhaps 
a bit easier to use from a language with distinguished-caller syntax, 
but otherwise, if your language isn't OO, it's trivial to provide the 
same stuff as procedures taking objects, since there's neither 
inheritance nor subclassing going on.  I.e., if you wanted to expose the 
XML library as data structures rather than object with getters, it's 
trivial to do so, and languages that don't support OO do this without 
any problem.

> 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.

That's called SAX, meaning "Simple API for XML".  Stupid name, but there 
you have it. It's also not XML. Generally speaking, a SAX parser isn't 
implemented in an OO kind of way. (Obviously, in languages like Java 
where there are no functions, yeah, it's implemented in an OO way. But 
in languages that support something other than or in addition to OO 
(like PHP), it's almost never implemented in an OO way.)  It's 
implemented instead as "here's the callbacks for handling various 
events" instead of "here's an instance of a class with a particular 
interface."   (True, it would probably be *better* as a class, but not 
significantly moreso, especially if it crashes to have two concurrent 
instances anyway.)

>   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.

Would be funky if true.  Sadly, even the Java implementation doesn't 
actually work right, and crashes if you use it in two threads at once, 
which would lead one to believe it's not actually storing everything it 
needs in the instance variables of the parser.

>   Should suffice to say that modules should be instantiable.

Fair enough.  Sort of OO without inheritance. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Invisible wrote:
> Darren New wrote:
> 
>> (I count "reuse" as the ability to take code already written and use 
>> it in ways not anticipated when it was written.)
> 
> Isn't that "extensibility", not "reusability"? You want to *extend* 
> existing software to do something it wasn't designed to do.

Well, the claims of the OO proponents were that the extensibility (via 
inheritance) would make the reusability much better. (Along with the 
encapsulation, of course.)

Extensibility is actually something different, when speaking in 
technical terms. Extensibility is the ability to add your own 
domain-specific stuff to your environment and have it have all the 
powers and basically be indistinguishable from the stuff that is 
privileged to come with the environment. E.g., there's nothing built-in 
functions can do that you can't, there's nothing programs that come with 
the OS can do that your programs can't, etc.

>> But particular OO libraries are IME limited to doing exactly what they 
>> were designed to do, without really being any more extensible than a 
>> procedural language with carefully crafted callbacks.
> 
> You're still talking about "extensible", not "reusable".

Well, no.

> With any half-decent OO language, this problem immediately goes away. 

Not really. Not in C++ or Java, for example. (Yes, you can do it in C++, 
but not because of the OO nature of it.)

> You can now write a sorting algorithm once for each container type (or 
> even once overall if you desire, but that's probably less efficient) and 
> you're done. This one sorting algorithm can then be reused anywhere you 
> need to sort data.

I can already do that in C. Look at the qsort routine. You're not 
talking about OO here. You're talking about how statically typed 
something is regardless of whether it's OO.

> These days OOP isn't the only paradigm that actually offers this 
> benefit, but the benefit is real none the less.

There are definitely benefits to OO. Being able to reuse existing code 
by subclassing it and overriding just that which isn't quite right (when 
the original designer hadn't anticipated you'd subclass it in that way) 
isn't one of them.   Certainly less so than some of the other mechanisms 
that have been invented without nearly as much hype.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   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.

> Would be funky if true.  Sadly, even the Java implementation doesn't 
> actually work right, and crashes if you use it in two threads at once, 
> which would lead one to believe it's not actually storing everything it 
> needs in the instance variables of the parser.

  Just because some library is buggy doesn't tell anything about the
reusability of OO code.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Just because some library is buggy doesn't tell anything about the
> reusability of OO code.

True. But it points out that OO doesn't solve many of the problems that 
make code non-reusable. :-)  I.e., if it's still easy to make the bugs 
that make things non-reusable, it's probably not as good for reusability 
as other paradigms that prevent such mistakes.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> Warp wrote:
>>   Just because some library is buggy doesn't tell anything about the
>> reusability of OO code.
> 
> True. But it points out that OO doesn't solve many of the problems that 
> make code non-reusable. :-)  

Well, at least, OO as implemented by Java. :-)  But we already know Java 
sucks pretty bad.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Invisible wrote:
> > You can now write a sorting algorithm once for each container type (or 
> > even once overall if you desire, but that's probably less efficient) and 
> > you're done. This one sorting algorithm can then be reused anywhere you 
> > need to sort data.

> I can already do that in C. Look at the qsort routine.

  Except that C's qsort can only be used to sort arrays, and additionally
each element must be addressable with a void*. Thus it cannot be used to
sort all possible (random access) data containers. (For example the data
container might not be a contiguous array, such as eg. a std::deque isn't,
or the array iterator might not be castable to and from void*, eg. because
it's larger than a single pointer.)

  (Not to talk about casting to and from void* is completely type-unsafe,
but that's another matter, of course.)

> You're not 
> talking about OO here. You're talking about how statically typed 
> something is regardless of whether it's OO.

  Specific algorithms are not good examples of OOP. Data containers are.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Just because some library is buggy doesn't tell anything about the
> > reusability of OO code.

> True. But it points out that OO doesn't solve many of the problems that 
> make code non-reusable. :-)  I.e., if it's still easy to make the bugs 
> that make things non-reusable, it's probably not as good for reusability 
> as other paradigms that prevent such mistakes.

  I think you are starting to stretch the argument.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Specific algorithms are not good examples of OOP. Data containers are.

OK. And yes, I'm stretching the argument a bit to see how far it can go. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Specific algorithms are not good examples of OOP. Data containers are.

> OK. And yes, I'm stretching the argument a bit to see how far it can go. :-)

  I think we can all agree that there's no silver bullet.
http://en.wikipedia.org/wiki/No_Silver_Bullet

  We can also agree that OOP did not bring the panacea it was supposed to,
after all, although it *did* bring a whole lot nevertheless. It's just not
the *ultimate* solution to all problems.

  The two main aspects of OOP are modularity and inheritance. Modularity
is a hugely useful paradigm, but inheritance, while sometimes useful, was
not after all the panacea it was supposed to be. Practice has diminished
the importance of inheritance as a tool quite a lot in the past ~20 years.

  What more or less surpassed inheritance in importance is generic
programming (by whatever means and paradigms you like). While some aspects
of generic programming are perhaps somewhat similar to inheritance, it has
nevertheless resulted to be more useful and efficient than pure inheritance
in many areas.

  Of course the definition of "generic programming" can be a bit fuzzy.
Perhaps it could be argued that C++ template metaprogramming and Haskell
functional programming are both different approaches at generic programming.
In general it could be said, perhaps a bit simplistically, that generic
programming is a way to write algorithms which will work for (almost)
any data type which meets certain criteria, without the algorithm having
to explicitly know what the data type in question is. In OOP this has
classically been achieved through inheritance, but generic programming is
often even more powerful and expressive than that (and often leads to
faster and more efficient code, both speedwise and memorywise).

  Of course this doesn't mean OOP is dead. Modularity is still, and will
always be, a hugely useful design tool. (Yes, also for reusability.)

-- 
                                                          - Warp

Post a reply to this message