RE: [opengoop] Interfaces

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

> Should an interface data structure be strictly typed or more=20
> flexible so that generic utilities can operate on it?

I just realized that if you set the "Expose Typedefs" option of "Flatten =
to
String", the type descriptors of Strict VI Refnums contain the same
Connector Pane Data that is returned by VI.ConnectorPaneData.R.vi (a =
locked
VI in the bld-maker project) when passed a generic VI Reference.

This will allow us to dynamically test an array of generic VI references
against an Interface Inheritance Cluster.  We can also populate an =
Interface
Inheritance Cluster with VI reference values by simply concatenating the =
VI
reference values and writing it to the Interface Inheritance Cluster as
flattened data (flattened data of a cluster is the concatenation of the
flattened data of the cluster's elements).

-Jim

> -----Original Message-----
> From: Jim Kring [mailto:ji...@ji...]=20
> Sent: Saturday, October 18, 2003 6:41 PM
> To: 'ope...@li...'
> Subject: RE: [opengoop] Interfaces
>=20
>=20
> Here's an thought...
>=20
> Could we define an interface (recursively) as being a cluster=20
> of interfaces and strict VI refnums, we could apply the=20
> inheritance cluster scheme of using the parents' interface=20
> clusters as the first elements of the child's interface=20
> cluster.  A class could have in its data store an=20
> "interfaces" cluster containing the interfaces that it implements.
>=20
> Should an interface data structure be strictly typed or more=20
> flexible so that generic utilities can operate on it?
>=20
> -Jim
>=20
>=20
> > -----Original Message-----
> > From: Jim Kring [mailto:ji...@ji...]
> > Sent: Saturday, October 18, 2003 5:04 PM
> > To: 'ope...@li...'
> > Subject: [opengoop] Interfaces
> >=20
> >=20
> > Hello All,
> >=20
> > I haven't seen this discussed within the context of
> > LabVIEW/GOOP circles so I thought that I would plant the seed.
> >=20
> > First, please correct me if I make any mistakes, as I'm not
> > an OOP expert...
> >=20
> > Interfaces are a useful OOP pattern that allows one to
> > implement multiple-inheritance-like features with a=20
> > Single-Inheritance framework.  An interface is a collection=20
> > of methods and their signatures (input/output data types). =20
> > For OpenGOOP we could define an interface as a set of VIs,=20
> > each with a specific method name and connector pane=20
> > interface.  An object implements the interface if it has all=20
> > the public methods that the interface defines and the=20
> > connector panes of the required VIs match the interface.  If=20
> > a class uses an interface, it could have the interface set by=20
> > passing it a reference to an object that implements the=20
> > interface.  There could be a generic VI called "Object Get=20
> > Signature.vi" That returns a list of public methods and VI=20
> > References (Strict VI References that have been Typecast to=20
> > Generic VI References, allowing them to be stored in an array=20
> > since different Strict Refnums are not of the same data=20
> > type).  This allows a class method that receives an object=20
> > reference to inspect the object's interface to see if it=20
> > implements a specific interface.  It then populates its own=20
> > private data with the VI References of the VIs that implement=20
> > the interface, typecasting them back to Strict VI Refnums (so=20
> > that it can use them with Call By Reference - note that this=20
> > only works if the References were originally opened as strict).
> >=20
> > For example, let's define an interface called Driver.  Driver
> > consists of three methods: Accelerate, Decelerate, and Turn=20
> > (we'll not worry about their inputs/outputs, for this=20
> > example).  The Car class needs a Driver.  In order to tell=20
> > the Car who its driver is at run-time, we call "Car Set=20
> > Driver.vi" passing it a reference to an object that=20
> > implements the Driver interface (Again, by "implements the=20
> > Driver interface" I mean that it has, but is not limited to,=20
> > methods named Accelerate, Decelerate, and Turn).  We could=20
> > then do interface type checking inside of "Car Set Driver.vi"=20
> > or wait until Car tries to call the interface VIs and see if=20
> > an error occurs.  The former is better, but might take a=20
> > little more work to programmatically inspect the interface VI=20
> > connector panes.  Can a set of generic utility VIs be created=20
> > for interface checking, or any other useful task in this=20
> > design pattern?
> >=20
> > Any thoughts?
> >=20
> > -Jim
> >=20
>=20