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