Does anyone know of a book that describes good ways of getting bunches of 
different types of software written in inadequate languages[*] to work together?

In other words, I have a bunch of code in C: A web browser, a graphical 
toolkit, a video decoder, a XMPP stack, an RTSP stack, an HTTP stack, an XML 
parser, etc etc etc. However, each of these things is in C or C++, so each 
is using their own memory manager, their own set of defines for things like 
eight-bit-unsigned-bytes, their own set of routines for unicode, their own 
mechanisms for message catalogs, their own set of routines for logging, 
their own set of routines for threading/event handling, etc etc etc.

What's a good way to take the video player that's interfaced into the web 
browser and move it to a different web browser, when that video player has 
grown tentacles into the web browser for things like receiving events, 
typedefs, logging, etc etc?

Basically, I'd expect it looks something like Design Patterns, or Design 
Anti-Patterns, only for various pieces of third-party code you need to make 
work together.



[*] Obviously, if a language already comes with a good logging library, 
unicode strings built in, classes and callback events and locking and 
threading and such, you'll find few libraries in that language that have 
incompatibilities there. Hence the term "inadequate".

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Does anyone know of a book that describes good ways of getting bunches of 
> different types of software written in inadequate languages[*] to work together?

  I don't really understand why such books would even exist.

  If a program has not been designed to be reusable, then it isn't. End of
story. You could try to hack it to become more reusable, but good luck with
that. And patience.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   If a program has not been designed to be reusable, then it isn't.

Well, it is, of course, if it's just a library exposing an API. The problem 
is the pile of things the program depends upon that aren't standardized, and 
so each program wants something different there.  I guess sort of the 
language-level equivalent of DLL Hell.

If you have several different parser libraries, for example (say, XML, HTTP 
headers, message catalogs) and they all depend on different implementations 
of unicode strings, what's a good way of making it so you don't have to 
convert between unicode string representations each time you move data from 
the message catalog to an XML record sent over HTTP?  That's the kind of 
question I'm asking.  Or even if it's just bunches of typedefs, considering 
the C and C++ languages lack enough parsability or after-compile metadata to 
make it easy to actually find the declarations and uses and do a global 
replace on type names.  (As in, try to correctly rename type "i8" to "int8" 
everywhere in the code without manually inspecting each instance.)

Of course, the more powerful the language, the easier it is to do some sort 
of translation between types there, up to the point where you have a 
language that (gasp) already has unicode strings built in from day one. (Or 
at least day N where N < the original authoring date of any code you want to 
use.)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Of course, the more powerful the language, the easier it is to do some sort 
> of translation between types there, up to the point where you have a 
> language that (gasp) already has unicode strings built in from day one.

  You can hardly blame C (developed in 1972) and C++ (developed in 1979) for
not having native support for Unicode (first standardized in 1991).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   You can hardly blame C (developed in 1972) and C++ (developed in 1979) for
> not having native support for Unicode (first standardized in 1991).

I have no idea why you think I'm blaming inanimate objects for anything at 
all. It's an example. I'm sure in 20 years I'll be complaining that the 
grammars for my speech recognition library and my natural language deduction 
library aren't compatible.

If I asked how to get a program written before graphics displays were common 
running on a modern UI, I'd get a whole raft of suggestions, everything from 
using a terminal emulator to using a VM to ....

Yet if I mention that there's a lack of information published about solving 
a common problem in computer programming, and I happen to mention that it's 
affecting my *C* programming, suddenly I'm somehow insulting you or 
something? You're upset that I'm programming in C and C++ and asking people 
how they solve the sorts of problems I'm encountering? I'm sorry you don't 
ever have that sort of problem, but if you haven't anything to add to the 
conversation, why not just let it go?


But yes, now that you mention it, I *am* exactly blaming C, first developed 
in 1972, for not having standard unicode support first standardized in 1991. 
What or who else would I blame for that, if blame must be assigned? Indeed, 
the fact that C predates applications where you need logging, unicode, 
network protocol stacks, message catalogs, and even standard size integers 
for talking to custom hardware is *exactly* the source of the problem I'm 
trying to solve. Why wouldn't I blame C for that? I certainly can't blame 
the inventors of C, and it's certainly the age of C that's the fault for it 
missing many of the features people commonly use 30 years after its invention...

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New schrieb:
> I have no idea why you think I'm blaming inanimate objects for anything 
> at all.

You know you've been spending too much time in the Aperture Science 
Enrichment Center when... :-P

Post a reply to this message

clipka wrote:
> Darren New schrieb:
>> I have no idea why you think I'm blaming inanimate objects for 
>> anything at all.
> 
> You know you've been spending too much time in the Aperture Science 
> Enrichment Center when... :-P

The Enrichment Center reminds you that the C programming language might 
threaten to stab you and, in fact, can speak.

--
Tim Cook
http://empyrean.freesitespace.net

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   You can hardly blame C (developed in 1972) and C++ (developed in 1979) for
> > not having native support for Unicode (first standardized in 1991).

> I have no idea why you think I'm blaming inanimate objects for anything at 
> all.

  I don't. It was just a figure of speech.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> If you have several different parser libraries, for example (say, XML, 
> HTTP headers, message catalogs) and they all depend on different 
> implementations of unicode strings, what's a good way of making it so 
> you don't have to convert between unicode string representations each 
> time you move data from the message catalog to an XML record sent over 
> HTTP?

I don't know of any books that suggest solutions, but you might consider 
writing your own set of bridge classes to go between the different 
libraries.

That is, say you'd have a class DN_Unicode_String (or whatever you end 
up calling it), you would define casting operations both from and to 
every other unicode string type used.

Then, in your code, the only type you use would be the 
DN_Unicode_String, and it would work automatically with all the other 
libraries.

It's an ugly solution, and in the end it just increases the number of 
types being used, but it would work.

...Chambers

Post a reply to this message

Chambers wrote:
> I don't know of any books that suggest solutions, but you might consider 
> writing your own set of bridge classes to go between the different 
> libraries.

Yeah, I thought of that. Then you have the problem of wedging it between all 
the other libraries, including those in C so you don't actually have 
classes. Easier to just modify the libraries to use the same types.

I.e., I understand how to brute force it. I was just wondering if there was 
something clever, along the lines of "Design Patterns", that would work at a 
somewhat higher level than the level of problems that "Design Patterns" 
tends to work at.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message