* Runtime object type determination/ runtime generic instantiation
@ 1997-11-06 0:00 Anthony Jenkins
1997-11-08 0:00 ` Jon S Anthony
0 siblings, 1 reply; 3+ messages in thread
From: Anthony Jenkins @ 1997-11-06 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Runtime object type determination/ runtime generic instantiation
1997-11-06 0:00 Runtime object type determination/ runtime generic instantiation Anthony Jenkins
@ 1997-11-08 0:00 ` Jon S Anthony
1997-11-10 0:00 ` Anthony Jenkins
0 siblings, 1 reply; 3+ messages in thread
From: Jon S Anthony @ 1997-11-08 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Runtime object type determination/ runtime generic instantiation
1997-11-08 0:00 ` Jon S Anthony
@ 1997-11-10 0:00 ` Anthony Jenkins
0 siblings, 0 replies; 3+ messages in thread
From: Anthony Jenkins @ 1997-11-10 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1997-11-10 0:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-11-06 0:00 Runtime object type determination/ runtime generic instantiation Anthony Jenkins
1997-11-08 0:00 ` Jon S Anthony
1997-11-10 0:00 ` Anthony Jenkins
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox