comp.lang.ada
 help / color / mirror / Atom feed
* A question about extending programs
@ 2001-08-02 22:06 Darren New
  2001-08-03  1:13 ` Ed Falis
  0 siblings, 1 reply; 2+ messages in thread
From: Darren New @ 2001-08-02 22:06 UTC (permalink / raw)



I have a question about extending Ada OO programs. I find that a great
deal of the programs I write wind up being a skeleton with code for a
bunch of different cases, and those cases tend to expand over time. For
example, a transaction processor with transactions getting added, a GUI
with menu options getting added, etc. In all these cases, there's
generally a mapping from something like a string to something like a
class: the transaction name mapping to a function that handles it, the
MIME type mapping to the plug-in that displays it, etc.


Take a specific example, which I hope is mostly right. I have a list of
file names. Each file has a particular extension. The extension tells
you the file format. Each format has a different way of generating a
thumbnail image.

In a more dynamic language (Java, Tcl, etc) where one can easily load
code on the fly, I generally map between file extensions and the name of
the file holding the code to handle that extension. This obviously won't
work (as easily) in Ada, but I don't mind relinking to add more
functionality.

For Ada, I'm postulating the existance of a "Register" procedure, which
would (in this example) take a String representing the file extension
and an access-to-procedure (or classwide type or something) and add it
to the list of known file extensions and how to handle them.

It seems clear to me that each image format handler should be in its own
package, and that the package body should call the Register routine to
register itself. Then adding a new image type handler consists of
implementing the routine to make thumbnails etc and adding a call to
"Register" in the package body, so it gets called when the package is
elaborated.

With me so far? OK, good. Say I have three such handlers in my program
now. Is it possible to add a forth without changing any source that's
already there? The real question that I think I need to have answered
is, how do I force the fourth handler to get linked in and elaborated
without a specific call in the main body area that references the
handler? In other words, there's nothing that "with"s the package. Do I
actually have to have a list of "with" statements, one for each package,
somewhere? Do I need to actually call something, or is "with"
sufficient? I suppose I could "with" a package from the main routine
that "withs" all the other packages, thereby basically building a list
of things I handle. Is that the best way?

As always, TIA for any suggestions!


-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand. dnew@san.rr.com
          Only a WIMP puts wallpaper on his desktop.



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: A question about extending programs
  2001-08-02 22:06 A question about extending programs Darren New
@ 2001-08-03  1:13 ` Ed Falis
  0 siblings, 0 replies; 2+ messages in thread
From: Ed Falis @ 2001-08-03  1:13 UTC (permalink / raw)


Darren New wrote:

> With me so far? OK, good. Say I have three such handlers in my program
> now. Is it possible to add a forth without changing any source that's
> already there? The real question that I think I need to have answered
> is, how do I force the fourth handler to get linked in and elaborated
> without a specific call in the main body area that references the
> handler? In other words, there's nothing that "with"s the package. Do I
> actually have to have a list of "with" statements, one for each package,
> somewhere? Do I need to actually call something, or is "with"
> sufficient? I suppose I could "with" a package from the main routine
> that "withs" all the other packages, thereby basically building a list
> of things I handle. Is that the best way?
>

Yeah, a fairly straightforward way to do it is to declare a child
package defining the new derivation, and add that child to the main's
context clauses.

- Ed



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-08-03  1:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-02 22:06 A question about extending programs Darren New
2001-08-03  1:13 ` Ed Falis

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox