Runtime object type determination/ runtime generic instantiation

Runtime object type determination/ runtime generic instantiation

[Anthony Jenkins]

I'm having to instantiate a generic package which can use any private
type (equality/assignment methods defined) for a type specified in a
file.  e.g. the string "character" would be read from a file and I'd
have to use my package instantiated for the type 'character'.

If runtime generic instantiation were possible I could avoid
instantiating the package for every single non-limited type there is,
and if runtime object type determination were possible I was thinking I
could determine how to handle the type in the package body at runtime
(since strings I believe are non-limited and differ substantially from
scalar non-limited types in their handling).

The package I have to create is one for (un)directed graphs, where the
vertices can represent numbers, characters or strings (I'm thinking more
generically than these 3 types so I can possibly use it later) where the
node value type is given in a file.  Am I looking at this wrong?  I'm
seeing a huge (well, 3-clause) CASE statement (after instantiating each
of 3 different graph packages) that calls whatever operations are
available from the package using that type.  Anyway, thanks in advance
for any pointers.


Anthony Jenkins
http://www.auburn.edu/~jenkian
abjenkins @ mindspring , com (Death to spammers)

-------------
"God is as real as I am," the old man replied.  My faith was
restored, for I knew Santa would never lie.

Re: Runtime object type determination/ runtime generic instantiation

[Jon S Anthony]

Anthony Jenkins <abjenkins@mindspring.com> writes:

> The package I have to create is one for (un)directed graphs, where the
> vertices can represent numbers, characters or strings (I'm thinking more
> generically than these 3 types so I can possibly use it later) where the
> node value type is given in a file.  Am I looking at this wrong?  I'm

It _seems_ like you certainly are looking at it "wrong".  Since you
are already dealing with a higher level structure (the nodes), why
don't you create a hierarchy of these?  Which would also be
incrementally extensible, dynamically dispatchable, etc.  Here's a
basic hack:

    type Node_Type is abstract tagged private;
        -- or better yet, limited private

    -- all the basic operations.  Could be abstract as well or a mix.

...

    type Number_Node_Type is abstract new Node_Type;

    ... all the common number operations...
...
    type Real_Number_Node_Type is new Number_Node_Type with private;
...
    type Integer_Number_Node_Type is new Number_Node_Type with private;

    -- or you can flip these around and derive one from the other
    -- depending on your point of view.
...
    -- For example, here's a similar situation where strings
    -- come from characters...
    --
    type Character_Node_Type is new Node_Type with private;
...
    type String_Node_Type is new Character_Node_Type with private;


and so on ...

/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Runtime object type determination/ runtime generic instantiation

[Anthony Jenkins]

Jon S Anthony wrote:
> 
> Anthony Jenkins <abjenkins@mindspring.com> writes:
> 
> > The package I have to create is one for (un)directed graphs, where the
> > vertices can represent numbers, characters or strings (I'm thinking more
> > generically than these 3 types so I can possibly use it later) where the
> > node value type is given in a file.  Am I looking at this wrong?  I'm
> 
> It _seems_ like you certainly are looking at it "wrong".  Since you
> are already dealing with a higher level structure (the nodes), why
> don't you create a hierarchy of these?  Which would also be
> incrementally extensible, dynamically dispatchable, etc.  Here's a
> basic hack:
> 
>     type Node_Type is abstract tagged private;
>         -- or better yet, limited private
> 
>     -- all the basic operations.  Could be abstract as well or a mix.
> 
> ...
> 
>     type Number_Node_Type is abstract new Node_Type;
> 
>     ... all the common number operations...
> ...
>     type Real_Number_Node_Type is new Number_Node_Type with private;
> ...
>     type Integer_Number_Node_Type is new Number_Node_Type with private;
> 
>     -- or you can flip these around and derive one from the other
>     -- depending on your point of view.
> ...
>     -- For example, here's a similar situation where strings
>     -- come from characters...
>     --
>     type Character_Node_Type is new Node_Type with private;
> ...
>     type String_Node_Type is new Character_Node_Type with private;
> 
> and so on ...
> 
> /Jon
> 

Thanks!  That *does* make a lot more sense... I wasn't thinking OO
enough.

Anthony Jenkins
http://www.auburn.edu/~jenkian
abjenkins @ mindspring , com (Death to spammers)

-------------
"God is as real as I am," the old man replied.  My faith was
restored, for I knew Santa would never lie.