Re: [OpenGToolkit-Developers] [opengoop] Class Type Inheritance Refnum

[Jim K. <ji...@ji...>]

Hi Niels,

Niels Harre wrote:

> Howdy,
> 
> First, - a small introduction:
> I have just joined the opengtoolkit developer forum (I've been listening 
> since the very start though). So, - please accept my appologies for beeing 
> too ignorant - not knowing which discussions you allready have had. I've 
> worked professional with LabVIEW for several years, and have been somewhat 
> active on info-lv. Within the last couple of years the scope of my work has 
> changed towards software configuration management/OOA/OOD, - occasionally I 
> still use LV. Privately,- I've tried different ways to implement e.g. 
> inherency in LV based on GOOP, but I think that working together under 
> OpenG will speed up the process significantly. So, - I think my primary 
> focus will be on the OpenGOOP project.
> 
> I have special interest in finding a solution in OpenGOOP for:
> - inherency
> - abstraction/interface
> 
> - also templates for different design patters, as identified by the Gang of 
> Four.

First, welcome to the list :-)

Second, in order to impliment OOP patterns in LabVIEW we need to make sure 
that we impliment inheritance correctly.  We'll know that we are doing it 
right, if our design allows us to impliment the patterns.  I think that we 
should, from the very start, make these patterns use cases upon which we can 
base our requirments.

> Second,- about Jim's mail:
> Just took a brief look at it.
> 
> My first impressions is: this is slick,- but I have (for now) a quick 
question:
> 
> Will this allways be type safe?
> 
> What about future versions of LV? Using this (implicitly casting a cluster 
> of a ref and a variant into a variant) could be too close to the way LV 
> represents data in memory. To me it actually looks like a flaw in LV 
> (assigning clusters of different types to each other)...
> 
> All the best
> ---Niels

Yes, Niels this is safe.  Coercion of cluster elements ("casting" is not the 
right word, here) is an expected behavior (feature) of LabVIEW.  Another 
thing to consider is that there isn't really any useful data (only default 
values) flowing through the variants at run-time.  Our current plan is to 
have the actual object reference be contained in the Generic Refnum's data 
(the Refnum in the outermost cluster).  However, type information will flow 
into a parent class's Refnum Input when it recieves a child object 
reference.  This might be useful for looking up and dynamically dispatching 
to the childs implimentation of a method (but a lookup of object Class Type 
might be possible from the refnum value alone).

In the next few days, I will post information and links to information 
contained within emails exchanged between me and Jean-Pierre Drolet, over the 
past 5 months.  We have discussed many issues already.

Cheers,

-Jim

> 
> 
> 
> At 14:54 08-10-2003 -0700, Jim Kring wrote:
> >I have just created a new page at OpenG.org called "Class Type Inheritance
> >Refnum":
> >
> ><http://www.openg.org/tiki/tiki-index.php?
page=Class+Type+Inheritance+Refnum>
> >
> >The Class Type Inheritance Refnum (invented/discovered by Jean-Pierre
> >Drolet) is a LabVIEW Data Structure scheme which behaves just like VI 
Server
> >object (GObj) refnums. It uses variant coercion within the structure to
> >allow a more child class's more-specific structural component to coerce 
into
> >it's class-type variant element.
> >
> >The Class Type Inheritance Refnum will be used as the refnum type for
> >OpenGOOP w/ Inheritance.  Please take a look at this.
> >
> >Cheers,
> >
> >-Jim
> >
> >
>