opengtoolkit-developers — OpenG Toolkit developers mailing list

[dynamicpalette] download available

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

I have made a LabVIEW 7.0 (Windows) download available for testing and
comments.  I will soon package this as an OpenG Package File for
installation with the OpenG Package Installer.  Currently it is a Zip =
file
that can be extracted into the LabVIEW directory.

http://www.openg.org/tiki/tiki-index.php?page=3DOpenG+Rsc%3A+Dynamic+Pale=
tte+V
iew

Installing this will create a Palette View named "Dynamic Palette View".
Each folder beneath <user.lib>/_Dynamic_Palette_View/ is synchronized =
with
the corresponding palette in the Dynamic Palette View.

I have been organizing CVS.  There is a module named dynamicpalette.  I =
will
soon be committing some documentation on the CVS module organization and =
a
developer howto doc.  I am also creating some tools to automate =
development
and test steps.  For example, I want to create a VI that will populate =
each
folder beneath <user.lib>/_Dynamic_Palette_View/ with a VI of the same =
name
as the folder.  This way, testing consists of looking in the palette =
menus
for a VI of the same name as the menu.

Please let me know if you are interested in working on this.  It =
requires
knowledge of the palettes/mnu-files which isn't very exciting, but it is =
a
useful skill for packaging reuse libraries.

Cheers,

-Jim

[dynamicpalette] Announcement

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

Hello All,

I wanted to announce that I am working on a new package.  It is a
development environment resource called the Dynamic Palette View.

The Dynamic Palette View is a Custom Palette View that allows VIs and
palette submenus to be added dynamically. This is made possible by
synchronizing every palette with a specific folder in a hierarchy of =
folders
that reflects the hierarchy structure of the palettes. This allows =
libraries
and VIs to be integrated into the palettes dynamically and =
programmatically.

Please visit the project page at OpenG.org:

http://www.openg.org/tiki/tiki-index.php?page=3DOpenG+Rsc%3A+Dynamic+Pale=
tte+V
iew

There is a design document, which is currently a work in progress.

-Jim

[opengoop] Data Storage and access (was: Re: [opengoop] Virtual Methods (Abstraction))

[Jean-Pierre D. <jea...@tr...>]

Hi all,

Jim,


from what I understand, you'll need many data storage , one for object pr=
otected data and one per class for private data. If there
is a storage for each class level, why don't we put both protected and pr=
ivate data in the same storage and have VIs to get access
for each class? To construct the whole object data we still use control t=
emplates for the object but fill it by reading object
storage. Specifically, to access whole object data, the leaf object (as o=
pposed to root) reads the whole parent data (for its class
level) and bundle its own protected data.

I see an advantage here as when the whole object data is accessed, code i=
s executed at each class level so the class is warned that
data is read or modified. Otherwise, when datastorage is created by the l=
eaf (root), methods to access the data are simple
read/write without the parents (childs being notified by the change. That=
's very important for encapsulation since it the current
implementation, the child can access and modify parent data.

In some other text based languages, access to data are truly methods. Whe=
n you define a property of an object, you also defines two
methods to read and write the property. It is not simply an assignment to=
 a memory space of the property. The statements

object.property =3D newvalue
value =3D object.property

are really executed as methods
object.set_property(newvalue)
value =3D object.get_property()

This way, data is encapsulated and only the class own methods can modify =
class data.

For OpenGOOP, the "car" object can actually modify the "speed" property o=
f the parent "vehicle" by setting a new value in the object
cluster but then the vehicle isn't notified immediatly of the value chang=
e. This could be done if the "car" invokes the "Vehicle Set
Speed.vi" method.

My point is that there is more in object data access than data storage I/=
O. If the class could store its own data and provide its
own methods to access it, then we would have encapsulation and protection=
. That doesn't trash the inheritance clusters we've
designed, just that these datatypes are to be bundled by accessing many l=
evels of data.

Jean-Pierre


----- Message d'origine -----=20
De : "Jim Kring" <ji...@ji...>
=C0 : <ope...@li...>
Envoy=E9 : 17 octobre, 2003 15:04
Objet : RE: [opengoop] Virtual Methods (Abstraction)


Niels,

I like your idea.  I have tried to use it as the basis for my example,
below.  In this example, each class stores its own protected and private
data; the strict inheritance structure is made accessible to descendants;
and only protected data (not private) are accessible to descendants.

How about using the following distinction?
 - Private: Only members of the class can access this data.
 - Protected: Only members of the class and its descendants can access th=
is
data.

Below is a scheme that I think will work.  I have also posted images, and=
 a
downloadable example to a new page at OpenG.org called "Strict Data
Inheritance Cluster With Private Attributes".  The page is located here:
http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inheritance+C=
luste
r+With+Private+Attributes

--- Class Data Structures ---

Each class has five clusters which are typedefs:
 - {Class Protected Data} =3D Class's protected data elements
 - {Class Private Data} =3D Class's private data elements
 - {Class Data Store} =3D  {{Class Protected Data}, {Class Private Data}}
 - {Class Inheritance Data} =3D {{Parent Inheritance Data}, {Class Protec=
ted
Data}}
 - {Class Data} =3D {{Class Inheritance Data}, {Class Private Data}}

--- Class Data Access VIs ---

Class Low-Level Data Access Utility VIs: - Gets/Sets {Class Data Store}.
Only callable from Class.
 - Class Get Data Store.vi
 - Class Get Data Store to Modify.vi
 - Class Set Data Store.vi

Data Access VIs for Class to Call: - Gets/Sets {Class Data}.  Only callab=
le
from Class.
 - Class Get Data.vi
 - Car Get Data to Modify.vi
 - Class Set Modified Data.vi

Data Access VIs for Child to Call: - Gets/Sets  {Class Inheritance Data}.
Only callable from Class's child.
 - Class Get Inheritance Data.vi
 - Class Get Inheritance Data to Modify.vi
 - Class Set Inheritance Data.vi

Let me know what you think.

-Jim


> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]
> On Behalf Of Niels Harre
> Sent: Thursday, October 16, 2003 5:08 PM
> To: ope...@li...
> Subject: RE: [opengoop] Virtual Methods (Abstraction)
>
>
> Hi Jim et al,
>
> I have a few comments:
>
> This "protected" data type is as indicated by it's name not
> as conservative
> as data carrying the term private! In LV - if a given child class can
> access it's parents "protected" data - it will/can be done,-
> also by end
> users. The architecture of LV is in this sense too open....
> so it cannot
> be avoided. Consequently - I suggest that if we want to
> implement different
> data types (private, protected, public)(and we do not know
> which (yet))
> then select an open data model, which isn't coupled too hard to the
> implementation.
>
> That's the main reason - I think - we should look more in the
> direction of
> your latter suggestion: the alternative to the inheritable
> data structure.
>
> The data structures could be arranged like this (very much as
> you suggest):
>
> parent class =3D {{public parent data}, ... <whatever data types> ...
> ,{private parent data}}
>
> {ancestor0 public data} =3D {public parent data}
> child0 class =3D {{public child0 data}, ... <whatever data types>
> ...,{private child0 data}, {ancestor0 public data}}
>
> {ancestor1 public data} =3D {{public child0 data}, {ancestor0
> public data}} child1 class =3D {{public child1 data}, ...
> <whatever data types>
> ...,{private child1 data}, {ancestor1 public data}}
>
> Still the bundle and unbundle (not by name) can be used.
>
> Further - this might be a step too  far - it's the
> implementation of the
> class which should instantiate memory space for any objects
> created. This
> implies that the constructor of a child classes should call
> it's inherited
> constructor, which again calls his inherited constructor.
> ....
>
>
> What=B4do you think?
>
> All the best,
> ---Niels
>
>
> At 18:46 15-10-2003 -0700, you wrote:
> >-=3D Re: encapsulation =3D-
> >
> >After doing some reading, I realize that the object data is
> considered
> >to be "protected" if descendants can access it, but end
> users cannot.
> >End user's only have access to the object vi (public)
> methods.  So, I
> >guess it is OK for descendants to access ancestor data.
> >
> >
> >-=3D Re: inheritable data structure =3D-
> >
> >One problem that I have with the inheritable data structure is that
> >since it is "inside-out", descendants have to "dig" into the object
> >data cluster in order to get to the descendent data -- the
> more levels
> >in the inheritance hierarchy, the deeper they have to go.
> This seems
> >backwards, and confusing to me.  I prefer digging into the
> object data
> >cluster in order to get to ancestor data.  Plus, descendents will
> >normally be accessing the descendant data, and not normally the
> >ancestor data, so descendent data should be easier to get to.
> >
> >The only (but very useful) advantage of the inheritable data
> structure
> >is that a descendant data type will coerce to an ancestor data type,
> >and ancestor "downcasts" to descendant using "Variant to
> Data".  This
> >has two implications.
> >
> >1) One does not have to bundle and unbundle data in "Class
> Get/Set Data
> >as Parent.vi", which means that there is no manual (or "scripting")
> >task that needs to occur in order to update the
> bundle/unbundle nodes
> >when a data type changes.  Note that "Bundle/Unbundle by
> Name" breaks
> >when an element name changes, and Bundle breaks when the number of
> >elements changes (However, Unbundle doesn't break when the number of
> >elements changes).
> >
> >2) Data could be stored in the oldest ancestor (root),
> rather than the
> >youngest descendant.  Does this have any advantages?  One,
> that I can
> >think of is that there will be no dynamic calls for accessing data.
> >However, does this amount to much and how much overhead will
> there be
> >if we are converting to variant and back very often, anyway?
> >
> >-=3D An alternative to the inheritable data structure =3D-
> >
> >The change that we made to the inheritable data structure of
> wrapping
> >the {class added data} in a cluster, can also be applied to the
> >standard inheritance cluster, for a benefit that eliminates
> problem #1,
> >above (bundle/unbundle growth).
> >
> >For example let's look at a Car's data cluster:
> >{Car Data} =3D=3D {{LandVehicle Data},{Car Added Data}}
> >Where:
> >{LandVehicle Data} =3D {{Vehicle Data}, {LandVehicle Added Data}}
> >
> >Since each object's data is a cluster of exactly two subclusters, we
> >can bundle and unbundle (not by name) without worrying about
> the nodes
> >growing in size.  Therefore {Object Added Data} can grow in size
> >without changing the number of elements in {Object Data}.
> >
> >I have posted an example of this on OpenG.org called "Strict Data
> >Inheritance Cluster".  The page is located at:
> >
> >http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inh
> eritance+C
> >luste
> >r
> >
> >
> >
> >-Jim
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: ope...@li...
> > > [mailto:ope...@li...]
> > > On Behalf Of Jean-Pierre Drolet
> > > Sent: Tuesday, October 14, 2003 5:42 PM
> > > To: ope...@li...
> > > Subject: Re: [opengoop] Virtual Methods (Abstraction)
> > >
> > >
> > > Ahh...
> > >
> > > I was sure you were talling about the "new" fact that an ancestor
> > > does have access to child data thru the introduced variant...
> > >
> > > The encapsulation issue also exists for embedded clusters
> datatypes.
> > > It may be possible for Class Get Data.vi to cast, unbundle and
> > > return only the class specific data. More easily with inheritance
> > > clusters since class specific data is bundled in a cluster. The
> > > problem I see actually is that the parent class isn't
> always aware
> > > when its data is accessed so it may be important that
> either a) the
> > > clild can't access parent data at all or b) it is allowed
> to modify
> > > it but all the ancestors Get/Set Data methods are invoked
> to notify
> > > that the data is accessed and modified. Maybe two methods can be
> > > used: Get/Set Class Data to access class specific data only
> > > and Get/Set Object Data to access all object data. In the
> > > latter, Get/Set methods are invoked for all classes to
> access data.
> > >
> > > It is also important for the object to have private data (not
> > > get/set outside the class) like internal state variables. These
> > > shouldn't be affected by get/set data operation on public
> variables.
> > > This private data need to be store in the object data space too.
> > >
> > >
> > >
> > > Jean-Pierre
> > >
> > >
> > > ----- Message d'origine -----
> > > De : "Jim Kring" <ji...@ji...>
> > > =C0 : <ope...@li...>
> > > Envoy=E9 : 13 octobre, 2003 22:23
> > > Objet : RE: [opengoop] Virtual Methods (Abstraction)
> > >
> > >
> > > Jean-Pierre,
> > >
> > > Actually what I am talking about is the inverse.  I am not too
> > > concerned with an ancestor having access to descendant data, but
> > > rather I am concerned with a descendant having access to
> ancestor's
> > > private data.  Right now there is no distinction between private
> > > data and public data -- all object data is public.  Therefore, a
> > > class cannot protect itself from a descendant that doesn't fully
> > > understand its implementation (and descendants shouldn't have to
> > > understand).  Maybe there could be two types of data storage,
> > > public and private.  Public data would be accessible to the
> > > descendants, via their object data clusters, and private data
> > > would not be accessible to descendants.  Private data will
> > > not need an inheritance scheme since it is only available to
> > > one class-level.
> > >
> > > -Jim
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: SF.net Giveback Program.
> > > SourceForge.net hosts over 70,000 Open Source Projects. See the
> > > people who have HELPED US provide better services: Click
> > > here: http://sourceforge.net/supporters.php
> > > _______________________________________________
> > > OpenGToolkit-Developers mailing list
> > > Ope...@li...
> > >
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-deve
lopers
> >
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>SourceForge.net hosts over 70,000 Open Source Projects. See the people
>who have HELPED US provide better services: Click here:
>http://sourceforge.net/supporters.php
>_______________________________________________
>OpenGToolkit-Developers mailing list
>Ope...@li...
>https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.n=
et
hosts over 70,000 Open Source Projects. See the people who have HELPED US
provide better services: Click here: http://sourceforge.net/supporters.ph=
p
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers



-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers

RE: [lvdata] Universal Probe

[Michael C. A. <mic...@im...>]

Jim,

I already modified my version to list [Cluster] and Array[] types. I am
working on the registering of recognized (typedef) clusters, and also
sending data to a central table display via queue. I will download the
latest version you mentioned below and add these mods, then I'll be happy to
send you the updates.

Mike

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of
Jim Kring
Sent: Saturday, October 25, 2003 7:33 PM
To: ope...@li...
Subject: RE: [lvdata] Universal Probe


Thanks for the feedback, Mike.

By the way, I have just (this morning) updated the Universal Probe page with
a new version that fixes a problem that prevented it from working with
TypeDefs.  In case you didn't know... you can subscribe to email updates
when new versions of this page are committed.  If you are logged in, you can
click on the eye icon  in the upper right corner of a page to watch
(monitor) that page and automatically receive email updates when it changes.


In general, I am not going to be evolving the Universal Probe as a "real"
project, but I might add features from time to time, especially if others
send me improvements (hint, hint ;-).

Cheers,

-Jim


> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]
> On Behalf Of Michael C. Ashe
> Sent: Thursday, October 23, 2003 2:59 PM
> To: ope...@li...
> Subject: RE: [lvdata] Universal Probe
>
>
> Jim,
>
> I think this is awesome! And not just the convenience, but
> the tree parser too. Well done.
>
> Now for the totally ungrateful, "we always want more" part...
>
> 1. When an item type is array or cluster, then it should say
> that in the Type column of the tree.
>
> 2. It would be great if we could supply the probe with an
> array of known cluster types/patterns, so that in the data
> column of the tree, it would say what type of cluster it is,
> or (Unknown type). Another version of this functionality
> would be if it displayed a control typedef or VI name.
>
> 3. I wasn't aware that a custom probe could be a VI. I
> thought it had to be a control. For a long time I have wanted
> a probe type that I could sprinkle in a dozen or more places
> and they would all send their data to a single display that
> would show me summarized data in a table format. (A tree is
> just a special table...). Your VIs show how to get there. I'm
> going to tweak a version of your probe to send data into a
> queue, then to a single display VI.
>
> Again, great work.
>
> Mike Ashe
>
> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]On
>  Behalf Of Jim Kring
> Sent: Thursday, October 23, 2003 1:13 AM
> To: ope...@li...
> Subject: [lvdata] Universal Probe
>
>
> Hello All,
>
> I have just created a new page on OpenG.org called ((OpenG
> Rsc: Universal Probe)).
>
> http://www.openg.org/tiki/tiki-index.php?page=OpenG+Rsc%3A+Uni
versal+Probe

The Universal Probe is a Custom Probe that can view any data, by populating
a LabVIEW Tree control with the data. Its input type is a Variant, and it
dynamically parses the data. The "Using the Universal Probe" section, below,
on how to use the Universal Probe to probe anything and everything.

There downloadable tool is packaged for easy installation into your Custom
Probes directory ("<My Documents>\LabVIEW Data\Probes").

This tool uses a VI called "Populate Tree Control with Variant Data.vi"
which uses a recursion into Variant technique based on the "OpenG Flatten to
XML.vi" and other lvdata examples.

Please take a look and please feel free to comment.

Cheers,

-Jim



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations Here's your
chance to show off your extensive product knowledge We want to know what you
know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program. Do you like
what SourceForge.net is doing for the Open Source Community?  Make a
contribution, and help us add new features and functionality. Click here:
http://sourceforge.net/donate/
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers

RE: [lvdata] Universal Probe

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

Thanks for the feedback, Mike.

By the way, I have just (this morning) updated the Universal Probe page =
with
a new version that fixes a problem that prevented it from working with
TypeDefs.  In case you didn't know... you can subscribe to email updates
when new versions of this page are committed.  If you are logged in, you =
can
click on the eye icon  in the upper right corner of a page to watch
(monitor) that page and automatically receive email updates when it =
changes.


In general, I am not going to be evolving the Universal Probe as a =
"real"
project, but I might add features from time to time, especially if =
others
send me improvements (hint, hint ;-).

Cheers,

-Jim


> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Michael C. Ashe
> Sent: Thursday, October 23, 2003 2:59 PM
> To: ope...@li...
> Subject: RE: [lvdata] Universal Probe
>=20
>=20
> Jim,
>=20
> I think this is awesome! And not just the convenience, but=20
> the tree parser too. Well done.
>=20
> Now for the totally ungrateful, "we always want more" part...
>=20
> 1. When an item type is array or cluster, then it should say=20
> that in the Type column of the tree.
>=20
> 2. It would be great if we could supply the probe with an=20
> array of known cluster types/patterns, so that in the data=20
> column of the tree, it would say what type of cluster it is,=20
> or (Unknown type). Another version of this functionality=20
> would be if it displayed a control typedef or VI name.
>=20
> 3. I wasn't aware that a custom probe could be a VI. I=20
> thought it had to be a control. For a long time I have wanted=20
> a probe type that I could sprinkle in a dozen or more places=20
> and they would all send their data to a single display that=20
> would show me summarized data in a table format. (A tree is=20
> just a special table...). Your VIs show how to get there. I'm=20
> going to tweak a version of your probe to send data into a=20
> queue, then to a single display VI.
>=20
> Again, great work.
>=20
> Mike Ashe
>=20
> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]On
>  Behalf Of Jim Kring
> Sent: Thursday, October 23, 2003 1:13 AM
> To: ope...@li...
> Subject: [lvdata] Universal Probe
>=20
>=20
> Hello All,
>=20
> I have just created a new page on OpenG.org called ((OpenG=20
> Rsc: Universal Probe)).
>=20
> http://www.openg.org/tiki/tiki-index.php?page=3DOpenG+Rsc%3A+Uni
versal+Probe

The Universal Probe is a Custom Probe that can view any data, by =
populating
a LabVIEW Tree control with the data. Its input type is a Variant, and =
it
dynamically parses the data. The "Using the Universal Probe" section, =
below,
on how to use the Universal Probe to probe anything and everything.

There downloadable tool is packaged for easy installation into your =
Custom
Probes directory ("<My Documents>\LabVIEW Data\Probes").

This tool uses a VI called "Populate Tree Control with Variant Data.vi"
which uses a recursion into Variant technique based on the "OpenG =
Flatten to
XML.vi" and other lvdata examples.

Please take a look and please feel free to comment.

Cheers,

-Jim



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations Here's your
chance to show off your extensive product knowledge We want to know what =
you
know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program. Do you =
like
what SourceForge.net is doing for the Open Source Community?  Make a
contribution, and help us add new features and functionality. Click =
here:
http://sourceforge.net/donate/
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers

RE: [lvdata] Universal Probe

[Michael C. A. <mic...@im...>]

Jim,

I think this is awesome! And not just the convenience, but the tree parser
too. Well done.

Now for the totally ungrateful, "we always want more" part...

1. When an item type is array or cluster, then it should say that in the
Type column of the tree.

2. It would be great if we could supply the probe with an array of known
cluster types/patterns, so that in the data column of the tree, it would say
what type of cluster it is, or (Unknown type). Another version of this
functionality would be if it displayed a control typedef or VI name.

3. I wasn't aware that a custom probe could be a VI. I thought it had to be
a control. For a long time I have wanted a probe type that I could sprinkle
in a dozen or more places and they would all send their data to a single
display that would show me summarized data in a table format. (A tree is
just a special table...). Your VIs show how to get there. I'm going to tweak
a version of your probe to send data into a queue, then to a single display
VI.

Again, great work.

Mike Ashe

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of
Jim Kring
Sent: Thursday, October 23, 2003 1:13 AM
To: ope...@li...
Subject: [lvdata] Universal Probe


Hello All,

I have just created a new page on OpenG.org called ((OpenG Rsc: Universal
Probe)).

http://www.openg.org/tiki/tiki-index.php?page=OpenG+Rsc%3A+Universal+Probe

The Universal Probe is a Custom Probe that can view any data, by populating
a LabVIEW Tree control with the data. Its input type is a Variant, and it
dynamically parses the data. The "Using the Universal Probe" section, below,
on how to use the Universal Probe to probe anything and everything.

There downloadable tool is packaged for easy installation into your Custom
Probes directory ("<My Documents>\LabVIEW Data\Probes").

This tool uses a VI called "Populate Tree Control with Variant Data.vi"
which uses a recursion into Variant technique based on the "OpenG Flatten to
XML.vi" and other lvdata examples.

Please take a look and please feel free to comment.

Cheers,

-Jim



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers

[lvdata] Universal Probe

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

Hello All,

I have just created a new page on OpenG.org called ((OpenG Rsc: =
Universal
Probe)).

http://www.openg.org/tiki/tiki-index.php?page=3DOpenG+Rsc%3A+Universal+Pr=
obe

The Universal Probe is a Custom Probe that can view any data, by =
populating
a LabVIEW Tree control with the data. Its input type is a Variant, and =
it
dynamically parses the data. The "Using the Universal Probe" section, =
below,
on how to use the Universal Probe to probe anything and everything.

There downloadable tool is packaged for easy installation into your =
Custom
Probes directory ("<My Documents>\LabVIEW Data\Probes").

This tool uses a VI called "Populate Tree Control with Variant Data.vi"
which uses a recursion into Variant technique based on the "OpenG =
Flatten to
XML.vi" and other lvdata examples.

Please take a look and please feel free to comment.

Cheers,

-Jim

[opengoop] Class Icon Editor

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

Hello all,

I have create a page on OpenG.org called ((OpenG Fwk: OpenGOOP: Class =
Icon
Editor)).

http://www.openg.org/tiki/tiki-index.php?page=3DOpenG+Fwk%3A+OpenGOOP%3A+=
Class
+Icon+Editor

-=3D Intro =3D-

OpenGOOP Classes (and other component-style groups of VIs) often have a
common "banner" of text accross the top of each VI's icon. It is a huge =
task
to modify the icon of every VI, when a change needs to be made. That's =
why a
tool to automate this is needed.

We are trying to define the use-cases and requirements for the Class =
Icon
Editor. If you have ideas, please let us know.

-=3D Use Cases =3D-

* A class's icon-banner is defined in an image file. Update the =
icon-banners
of all class VIs with the icon-banner stored in the image file.
* A class's icon information is stored in a meta-information file (INI, =
XML,
etc.) that defines the banner text, text color, banner color, icon =
border
color, etc. The icon-banner image is programatically created and the
icon-banners of all class VIs is updated with this image.

-=3D Example =3D-

I have created a tool called Update_Class_Icon-Banner that is available =
for
download.  It impliments Use Case #1.  It is written in LabVIEW 7.0, =
using
some new VI Methods and Picture Control VIs.


-Jim

RE: [opengoop] automatic call of destructor at garbage collection time

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

Philippe,
=20
Yes, that could work.  There should only be one reference for each data
store.  When the object is created, you could pass this reference to a
process that (1) opens a new VI reference to the data store, then (2) =
polls
the original reference until it becomes invalid, then (3) invokes the =
object
destructor, passing it the new data store reference.
=20
Thanks,
=20
-Jim
=20
 -----Original Message-----
From: ope...@li...
[mailto:ope...@li...] On Behalf =
Of PJ
M
Sent: Saturday, October 18, 2003 5:20 PM
To: ope...@li...
Subject: Re: [opengoop] automatic call of destructor at garbage =
collection
time



Jim,
=20
I have and idea, but I am not sure if it qualify as easy though.
We could keep a buffer of all opened VI Refs and whenever the spawn =
process
is left with only one reference (The one the spawn process opened) to a
given VI, then the VI went Idle.
=20
Philippe

Jim Kring <ji...@ji...> wrote:

I am trying to think of a way (preferably simple) to have the destructor
automatically called when object garbage collection occurs. OpenGOOP =
object
data-stores are reentrant LV2 globals which are called by reference. In
fact the object reference is a VI Reference. When the call chain that
instantiated the object goes idle, the data store VI is garbage =
collected by
LabVIEW. It would be nice to be able to intercept this and run the
destructor method of the object, automatically. This would make =
debugging a
lot easier In order to do this we would need to spawn a process that =
opens
a reference to the object LV2 global, so that it does not get garbage
collected. Then we would need to poll the execution state of the =
top-level
VI in the call chain that instantiated the object. When this top-level =
VI
goes idle we would then invoke the destructor. What would make this much
easier, is if the event structure had a VI Event called "Going Idle" or
similar.

Any thoughts?

-Jim



-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers



  _____ =20

Do you Yahoo!?
The
<http://shopping.yahoo.com/?__yltc=3Ds%3A150000443%2Cd%3A22708228%2Cslk%3=
Atext
%2Csec%3Amail> New Yahoo! Shopping - with improved product search

RE: [opengoop] Interfaces

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

Here's an thought...

Could we define an interface (recursively) as being a cluster of interfaces
and strict VI refnums, we could apply the inheritance cluster scheme of
using the parents' interface clusters as the first elements of the child's
interface cluster.  A class could have in its data store an "interfaces"
cluster containing the interfaces that it implements.

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

-Jim


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

Re: [opengoop] automatic call of destructor at garbage collection time

[PJ M <pjm...@ya...>]

Jim,
 
I have and idea, but I am not sure if it qualify as easy though.
We could keep a buffer of all opened VI Refs and whenever the spawn process is left with only one reference (The one the spawn process opened) to a given VI, then the VI went Idle.
 
Philippe

Jim Kring <ji...@ji...> wrote:
I am trying to think of a way (preferably simple) to have the destructor
automatically called when object garbage collection occurs. OpenGOOP object
data-stores are reentrant LV2 globals which are called by reference. In
fact the object reference is a VI Reference. When the call chain that
instantiated the object goes idle, the data store VI is garbage collected by
LabVIEW. It would be nice to be able to intercept this and run the
destructor method of the object, automatically. This would make debugging a
lot easier In order to do this we would need to spawn a process that opens
a reference to the object LV2 global, so that it does not get garbage
collected. Then we would need to poll the execution state of the top-level
VI in the call chain that instantiated the object. When this top-level VI
goes idle we would then invoke the destructor. What would make this much
easier, is if the event structure had a VI Event called "Going Idle" or
similar.

Any thoughts?

-Jim



-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers

---------------------------------
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

[opengoop] Interfaces

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

Hello All,

I haven't seen this discussed within the context of LabVIEW/GOOP circles =
so
I thought that I would plant the seed.

First, please correct me if I make any mistakes, as I'm not an OOP =
expert...

Interfaces are a useful OOP pattern that allows one to implement
multiple-inheritance-like features with a Single-Inheritance framework.  =
An
interface is a collection of methods and their signatures (input/output =
data
types).  For OpenGOOP we could define an interface as a set of VIs, each
with a specific method name and connector pane interface.  An object
implements the interface if it has all the public methods that the =
interface
defines and the connector panes of the required VIs match the interface. =
 If
a class uses an interface, it could have the interface set by passing it =
a
reference to an object that implements the interface.  There could be a
generic VI called "Object Get Signature.vi" That returns a list of =
public
methods and VI References (Strict VI References that have been Typecast =
to
Generic VI References, allowing them to be stored in an array since
different Strict Refnums are not of the same data type).  This allows a
class method that receives an object reference to inspect the object's
interface to see if it implements a specific interface.  It then =
populates
its own private data with the VI References of the VIs that implement =
the
interface, typecasting them back to Strict VI Refnums (so that it can =
use
them with Call By Reference - note that this only works if the =
References
were originally opened as strict).

For example, let's define an interface called Driver.  Driver consists =
of
three methods: Accelerate, Decelerate, and Turn (we'll not worry about =
their
inputs/outputs, for this example).  The Car class needs a Driver.  In =
order
to tell the Car who its driver is at run-time, we call "Car Set =
Driver.vi"
passing it a reference to an object that implements the Driver interface
(Again, by "implements the Driver interface" I mean that it has, but is =
not
limited to, methods named Accelerate, Decelerate, and Turn).  We could =
then
do interface type checking inside of "Car Set Driver.vi" or wait until =
Car
tries to call the interface VIs and see if an error occurs.  The former =
is
better, but might take a little more work to programmatically inspect =
the
interface VI connector panes.  Can a set of generic utility VIs be =
created
for interface checking, or any other useful task in this design pattern?

Any thoughts?

-Jim

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

[opengoop] automatic call of destructor at garbage collection time

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

I am trying to think of a way (preferably simple) to have the destructor
automatically called when object garbage collection occurs.  OpenGOOP =
object
data-stores are reentrant LV2 globals which are called by reference.  In
fact the object reference is a VI Reference.  When the call chain that
instantiated the object goes idle, the data store VI is garbage =
collected by
LabVIEW.  It would be nice to be able to intercept this and run the
destructor method of the object, automatically.  This would make =
debugging a
lot easier  In order to do this we would need to spawn a process that =
opens
a reference to the object LV2 global, so that it does not get garbage
collected.  Then we would need to poll the execution state of the =
top-level
VI in the call chain that instantiated the object.  When this top-level =
VI
goes idle we would then invoke the destructor.  What would make this =
much
easier, is if the event structure had a VI Event called "Going Idle" or
similar.

Any thoughts?

-Jim

RE: Mailing list archive is now working

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

Testing...

Testing the threading feature of Tiki email to forum gateway for a =
potential
bug.  Please disregard this email.

-Jim

RE: [opengoop] Virtual Methods (Abstraction)

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

So, back to the topic of virtual methods.  I have some ideas, questions, =
and
comments...

-=3D Virtual Methods: Loading into Memory =3D-

Jean-Pierre and I talked about this previously and agreed (if I remember
correctly) that implementations of virtual methods should only be loaded
into memory if they are not overrided by a descendant.  This is because =
the
overrided VI might not have its dependencies met, or would just add =
extra
overhead.  This means that we cannot use Static VI Refnum constants (LV7
feature), or equivalent mechanism of statically linking in our dynamic
method VIs to guarantee that they are in memory (this allows opening
references by name, rather than by path).  So we need some other =
mechanism
of locating them at run-time.  We could first look for them in a known
location beneath the class folder (like ./Public), and second look in =
the
same location as the VI that's looking for them ( <Current VI's Path> +
<../"ClassName MethodName.vi"> ).  The latter would be used in case the =
app
were built into an application or packaged for distribution.  I have =
posted
an example of this here:

http://www.openg.org/tiki/tiki-download_wiki_attachment.php?attId=3D25


-=3D Virtual Methods: Interface Check =3D-

Should a constructor check (at object instantiation time) to make sure =
that
its child implementation of virtual methods have the correct interface? =
This
means that the constructor might have to perform some connector pane =
check
of all the method VIs that it finds in the child class.  This requires
loading them all into memory.  However, what if the child class's
constructor instead passed an interface descriptor down to the parent's
constructor that contained connector pane info (control connector pane
positions and datatypes) for all its method VIs, along with the method =
names
and paths?  Then we could type-check at object construction time without
actually loading the virtual methods at that time.


-=3D Virtual Methods: Object Instantiation =3D-

When a Class constructor is called by its Child's constructor, it =
receives
(either as an input or by some indirect mechanism) a list of methods =
that
have been implemented by the classes descendants.  It appends to the =
list
all of its methods whose names are not already in the list (this is how
methods are overrided).  Then, it passes this list to its Parent's
constructor.  This process continues up the class hierarchy until the =
root
class is constructed.

Any thoughts?

-Jim

[opengoop] Should private methods enforce call chain?

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

I was thinking that all private methods (class VIs that are not public
methods) should check their call chain to make sure that they are called
only by their own class (or their child/parent in some cases)?  This would
be nice way to enforce encapsulation.
 
Any thoughts?
 
-Jim

RE: [opengoop] Virtual Methods (Abstraction)

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

Niels,

I like your idea.  I have tried to use it as the basis for my example,
below.  In this example, each class stores its own protected and private
data; the strict inheritance structure is made accessible to =
descendants;
and only protected data (not private) are accessible to descendants.

How about using the following distinction?
 - Private: Only members of the class can access this data.
 - Protected: Only members of the class and its descendants can access =
this
data.

Below is a scheme that I think will work.  I have also posted images, =
and a
downloadable example to a new page at OpenG.org called "Strict Data
Inheritance Cluster With Private Attributes".  The page is located here:
http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inheritance+C=
luste
r+With+Private+Attributes

--- Class Data Structures ---

Each class has five clusters which are typedefs:
 - {Class Protected Data} =3D Class's protected data elements
 - {Class Private Data} =3D Class's private data elements
 - {Class Data Store} =3D  {{Class Protected Data}, {Class Private =
Data}}
 - {Class Inheritance Data} =3D {{Parent Inheritance Data}, {Class =
Protected
Data}}
 - {Class Data} =3D {{Class Inheritance Data}, {Class Private Data}}

--- Class Data Access VIs ---

Class Low-Level Data Access Utility VIs: - Gets/Sets {Class Data Store}.
Only callable from Class.
 - Class Get Data Store.vi
 - Class Get Data Store to Modify.vi
 - Class Set Data Store.vi

Data Access VIs for Class to Call: - Gets/Sets {Class Data}.  Only =
callable
from Class.
 - Class Get Data.vi
 - Car Get Data to Modify.vi
 - Class Set Modified Data.vi

Data Access VIs for Child to Call: - Gets/Sets  {Class Inheritance =
Data}.
Only callable from Class's child.
 - Class Get Inheritance Data.vi
 - Class Get Inheritance Data to Modify.vi
 - Class Set Inheritance Data.vi

Let me know what you think.

-Jim


> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Niels Harre
> Sent: Thursday, October 16, 2003 5:08 PM
> To: ope...@li...
> Subject: RE: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Hi Jim et al,
>=20
> I have a few comments:
>=20
> This "protected" data type is as indicated by it's name not=20
> as conservative=20
> as data carrying the term private! In LV - if a given child class can=20
> access it's parents "protected" data - it will/can be done,-=20
> also by end=20
> users. The architecture of LV is in this sense too open.... =20
> so it cannot=20
> be avoided. Consequently - I suggest that if we want to=20
> implement different=20
> data types (private, protected, public)(and we do not know=20
> which (yet))=20
> then select an open data model, which isn't coupled too hard to the=20
> implementation.
>=20
> That's the main reason - I think - we should look more in the=20
> direction of=20
> your latter suggestion: the alternative to the inheritable=20
> data structure.
>=20
> The data structures could be arranged like this (very much as=20
> you suggest):
>=20
> parent class =3D {{public parent data}, ... <whatever data types> ...=20
> ,{private parent data}}
>=20
> {ancestor0 public data} =3D {public parent data}
> child0 class =3D {{public child0 data}, ... <whatever data types>=20
> ...,{private child0 data}, {ancestor0 public data}}
>=20
> {ancestor1 public data} =3D {{public child0 data}, {ancestor0=20
> public data}} child1 class =3D {{public child1 data}, ...=20
> <whatever data types>=20
> ...,{private child1 data}, {ancestor1 public data}}
>=20
> Still the bundle and unbundle (not by name) can be used.
>=20
> Further - this might be a step too  far - it's the=20
> implementation of the=20
> class which should instantiate memory space for any objects=20
> created. This=20
> implies that the constructor of a child classes should call=20
> it's inherited=20
> constructor, which again calls his inherited constructor.
> ....
>=20
>=20
> What=B4do you think?
>=20
> All the best,
> ---Niels
>=20
>=20
> At 18:46 15-10-2003 -0700, you wrote:
> >-=3D Re: encapsulation =3D-
> >
> >After doing some reading, I realize that the object data is=20
> considered=20
> >to be "protected" if descendants can access it, but end=20
> users cannot. =20
> >End user's only have access to the object vi (public)=20
> methods.  So, I=20
> >guess it is OK for descendants to access ancestor data.
> >
> >
> >-=3D Re: inheritable data structure =3D-
> >
> >One problem that I have with the inheritable data structure is that=20
> >since it is "inside-out", descendants have to "dig" into the object=20
> >data cluster in order to get to the descendent data -- the=20
> more levels=20
> >in the inheritance hierarchy, the deeper they have to go. =20
> This seems=20
> >backwards, and confusing to me.  I prefer digging into the=20
> object data=20
> >cluster in order to get to ancestor data.  Plus, descendents will=20
> >normally be accessing the descendant data, and not normally the=20
> >ancestor data, so descendent data should be easier to get to.
> >
> >The only (but very useful) advantage of the inheritable data=20
> structure=20
> >is that a descendant data type will coerce to an ancestor data type,=20
> >and ancestor "downcasts" to descendant using "Variant to=20
> Data".  This=20
> >has two implications.
> >
> >1) One does not have to bundle and unbundle data in "Class=20
> Get/Set Data=20
> >as Parent.vi", which means that there is no manual (or "scripting")=20
> >task that needs to occur in order to update the=20
> bundle/unbundle nodes=20
> >when a data type changes.  Note that "Bundle/Unbundle by=20
> Name" breaks=20
> >when an element name changes, and Bundle breaks when the number of=20
> >elements changes (However, Unbundle doesn't break when the number of=20
> >elements changes).
> >
> >2) Data could be stored in the oldest ancestor (root),=20
> rather than the=20
> >youngest descendant.  Does this have any advantages?  One,=20
> that I can=20
> >think of is that there will be no dynamic calls for accessing data. =20
> >However, does this amount to much and how much overhead will=20
> there be=20
> >if we are converting to variant and back very often, anyway?
> >
> >-=3D An alternative to the inheritable data structure =3D-
> >
> >The change that we made to the inheritable data structure of=20
> wrapping=20
> >the {class added data} in a cluster, can also be applied to the=20
> >standard inheritance cluster, for a benefit that eliminates=20
> problem #1,=20
> >above (bundle/unbundle growth).
> >
> >For example let's look at a Car's data cluster:
> >{Car Data} =3D=3D {{LandVehicle Data},{Car Added Data}}
> >Where:
> >{LandVehicle Data} =3D {{Vehicle Data}, {LandVehicle Added Data}}
> >
> >Since each object's data is a cluster of exactly two subclusters, we=20
> >can bundle and unbundle (not by name) without worrying about=20
> the nodes=20
> >growing in size.  Therefore {Object Added Data} can grow in size=20
> >without changing the number of elements in {Object Data}.
> >
> >I have posted an example of this on OpenG.org called "Strict Data=20
> >Inheritance Cluster".  The page is located at:
> >
> >http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inh
> eritance+C
> >luste
> >r
> >
> >
> >
> >-Jim
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: ope...@li...
> > > [mailto:ope...@li...]
> > > On Behalf Of Jean-Pierre Drolet
> > > Sent: Tuesday, October 14, 2003 5:42 PM
> > > To: ope...@li...
> > > Subject: Re: [opengoop] Virtual Methods (Abstraction)
> > >
> > >
> > > Ahh...
> > >
> > > I was sure you were talling about the "new" fact that an ancestor=20
> > > does have access to child data thru the introduced variant...
> > >
> > > The encapsulation issue also exists for embedded clusters=20
> datatypes.=20
> > > It may be possible for Class Get Data.vi to cast, unbundle and=20
> > > return only the class specific data. More easily with inheritance=20
> > > clusters since class specific data is bundled in a cluster. The=20
> > > problem I see actually is that the parent class isn't=20
> always aware=20
> > > when its data is accessed so it may be important that=20
> either a) the=20
> > > clild can't access parent data at all or b) it is allowed=20
> to modify=20
> > > it but all the ancestors Get/Set Data methods are invoked=20
> to notify=20
> > > that the data is accessed and modified. Maybe two methods can be
> > > used: Get/Set Class Data to access class specific data only
> > > and Get/Set Object Data to access all object data. In the
> > > latter, Get/Set methods are invoked for all classes to=20
> access data.
> > >
> > > It is also important for the object to have private data (not=20
> > > get/set outside the class) like internal state variables. These=20
> > > shouldn't be affected by get/set data operation on public=20
> variables.=20
> > > This private data need to be store in the object data space too.
> > >
> > >
> > >
> > > Jean-Pierre
> > >
> > >
> > > ----- Message d'origine -----
> > > De : "Jim Kring" <ji...@ji...>
> > > =C0 : <ope...@li...>
> > > Envoy=E9 : 13 octobre, 2003 22:23
> > > Objet : RE: [opengoop] Virtual Methods (Abstraction)
> > >
> > >
> > > Jean-Pierre,
> > >
> > > Actually what I am talking about is the inverse.  I am not too=20
> > > concerned with an ancestor having access to descendant data, but=20
> > > rather I am concerned with a descendant having access to=20
> ancestor's=20
> > > private data.  Right now there is no distinction between private=20
> > > data and public data -- all object data is public.  Therefore, a=20
> > > class cannot protect itself from a descendant that doesn't fully=20
> > > understand its implementation (and descendants shouldn't have to
> > > understand).  Maybe there could be two types of data storage,
> > > public and private.  Public data would be accessible to the
> > > descendants, via their object data clusters, and private data
> > > would not be accessible to descendants.  Private data will
> > > not need an inheritance scheme since it is only available to
> > > one class-level.
> > >
> > > -Jim
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: SF.net Giveback Program.=20
> > > SourceForge.net hosts over 70,000 Open Source Projects. See the=20
> > > people who have HELPED US provide better services: Click
> > > here: http://sourceforge.net/supporters.php
> > > _______________________________________________
> > > OpenGToolkit-Developers mailing list=20
> > > Ope...@li...
> > >=20
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-deve
lopers
> >
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.=20
>SourceForge.net hosts over 70,000 Open Source Projects. See the people=20
>who have HELPED US provide better services: Click here:=20
>http://sourceforge.net/supporters.php
>_______________________________________________
>OpenGToolkit-Developers mailing list=20
>Ope...@li...
>https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. =
SourceForge.net
hosts over 70,000 Open Source Projects. See the people who have HELPED =
US
provide better services: Click here: =
http://sourceforge.net/supporters.php
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers

RE: [opengoop] Virtual Methods (Abstraction)

[Niels H. <ni...@ha...>]

Hi Jim et al,

I have a few comments:

This "protected" data type is as indicated by it's name not as conservative 
as data carrying the term private! In LV - if a given child class can 
access it's parents "protected" data - it will/can be done,- also by end 
users. The architecture of LV is in this sense too open....  so it cannot 
be avoided. Consequently - I suggest that if we want to implement different 
data types (private, protected, public)(and we do not know which (yet)) 
then select an open data model, which isn't coupled too hard to the 
implementation.

That's the main reason - I think - we should look more in the direction of 
your latter suggestion: the alternative to the inheritable data structure.

The data structures could be arranged like this (very much as you suggest):

parent class = {{public parent data}, ... <whatever data types> ... 
,{private parent data}}

{ancestor0 public data} = {public parent data}
child0 class = {{public child0 data}, ... <whatever data types> 
...,{private child0 data}, {ancestor0 public data}}

{ancestor1 public data} = {{public child0 data}, {ancestor0 public data}}
child1 class = {{public child1 data}, ... <whatever data types> 
...,{private child1 data}, {ancestor1 public data}}

Still the bundle and unbundle (not by name) can be used.

Further - this might be a step too  far - it's the implementation of the 
class which should instantiate memory space for any objects created. This 
implies that the constructor of a child classes should call it's inherited 
constructor, which again calls his inherited constructor.
....


What´do you think?

All the best,
---Niels


At 18:46 15-10-2003 -0700, you wrote:
>-= Re: encapsulation =-
>
>After doing some reading, I realize that the object data is considered to be
>"protected" if descendants can access it, but end users cannot.  End user's
>only have access to the object vi (public) methods.  So, I guess it is OK
>for descendants to access ancestor data.
>
>
>-= Re: inheritable data structure =-
>
>One problem that I have with the inheritable data structure is that since it
>is "inside-out", descendants have to "dig" into the object data cluster in
>order to get to the descendent data -- the more levels in the inheritance
>hierarchy, the deeper they have to go.  This seems backwards, and confusing
>to me.  I prefer digging into the object data cluster in order to get to
>ancestor data.  Plus, descendents will normally be accessing the descendant
>data, and not normally the ancestor data, so descendent data should be
>easier to get to.
>
>The only (but very useful) advantage of the inheritable data structure is
>that a descendant data type will coerce to an ancestor data type, and
>ancestor "downcasts" to descendant using "Variant to Data".  This has two
>implications.
>
>1) One does not have to bundle and unbundle data in "Class Get/Set Data as
>Parent.vi", which means that there is no manual (or "scripting") task that
>needs to occur in order to update the bundle/unbundle nodes when a data type
>changes.  Note that "Bundle/Unbundle by Name" breaks when an element name
>changes, and Bundle breaks when the number of elements changes (However,
>Unbundle doesn't break when the number of elements changes).
>
>2) Data could be stored in the oldest ancestor (root), rather than the
>youngest descendant.  Does this have any advantages?  One, that I can think
>of is that there will be no dynamic calls for accessing data.  However, does
>this amount to much and how much overhead will there be if we are converting
>to variant and back very often, anyway?
>
>-= An alternative to the inheritable data structure =-
>
>The change that we made to the inheritable data structure of wrapping the
>{class added data} in a cluster, can also be applied to the standard
>inheritance cluster, for a benefit that eliminates problem #1, above
>(bundle/unbundle growth).
>
>For example let's look at a Car's data cluster:
>{Car Data} == {{LandVehicle Data},{Car Added Data}}
>Where:
>{LandVehicle Data} = {{Vehicle Data}, {LandVehicle Added Data}}
>
>Since each object's data is a cluster of exactly two subclusters, we can
>bundle and unbundle (not by name) without worrying about the nodes growing
>in size.  Therefore {Object Added Data} can grow in size without changing
>the number of elements in {Object Data}.
>
>I have posted an example of this on OpenG.org called "Strict Data
>Inheritance Cluster".  The page is located at:
>
>http://www.openg.org/tiki/tiki-index.php?page=Strict+Data+Inheritance+Cluste
>r
>
>
>
>-Jim
>
>
>
>
> > -----Original Message-----
> > From: ope...@li...
> > [mailto:ope...@li...]
> > On Behalf Of Jean-Pierre Drolet
> > Sent: Tuesday, October 14, 2003 5:42 PM
> > To: ope...@li...
> > Subject: Re: [opengoop] Virtual Methods (Abstraction)
> >
> >
> > Ahh...
> >
> > I was sure you were talling about the "new" fact that an
> > ancestor does have access to child data thru the introduced variant...
> >
> > The encapsulation issue also exists for embedded clusters
> > datatypes. It may be possible for Class Get Data.vi to cast,
> > unbundle and return only the class specific data. More easily
> > with inheritance clusters since class specific data is
> > bundled in a cluster. The problem I see actually is that the
> > parent class isn't always aware when its data is accessed so
> > it may be important that either a) the clild can't access
> > parent data at all or b) it is allowed to modify it but all
> > the ancestors Get/Set Data methods are invoked to notify that
> > the data is accessed and modified. Maybe two methods can be
> > used: Get/Set Class Data to access class specific data only
> > and Get/Set Object Data to access all object data. In the
> > latter, Get/Set methods are invoked for all classes to access data.
> >
> > It is also important for the object to have private data (not
> > get/set outside the class) like internal state variables.
> > These shouldn't be affected by get/set data operation on
> > public variables. This private data need to be store in the
> > object data space too.
> >
> >
> >
> > Jean-Pierre
> >
> >
> > ----- Message d'origine -----
> > De : "Jim Kring" <ji...@ji...>
> > À : <ope...@li...>
> > Envoyé : 13 octobre, 2003 22:23
> > Objet : RE: [opengoop] Virtual Methods (Abstraction)
> >
> >
> > Jean-Pierre,
> >
> > Actually what I am talking about is the inverse.  I am not
> > too concerned with an ancestor having access to descendant
> > data, but rather I am concerned with a descendant having
> > access to ancestor's private data.  Right now there is no
> > distinction between private data and public data -- all
> > object data is public.  Therefore, a class cannot protect
> > itself from a descendant that doesn't fully understand its
> > implementation (and descendants shouldn't have to
> > understand).  Maybe there could be two types of data storage,
> > public and private.  Public data would be accessible to the
> > descendants, via their object data clusters, and private data
> > would not be accessible to descendants.  Private data will
> > not need an inheritance scheme since it is only available to
> > one class-level.
> >
> > -Jim
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > SourceForge.net hosts over 70,000 Open Source Projects. See
> > the people who have HELPED US provide better services: Click
> > here: http://sourceforge.net/supporters.php
> > _______________________________________________
> > OpenGToolkit-Developers mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
> >
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>SourceForge.net hosts over 70,000 Open Source Projects.
>See the people who have HELPED US provide better services:
>Click here: http://sourceforge.net/supporters.php
>_______________________________________________
>OpenGToolkit-Developers mailing list
>Ope...@li...
>https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers

[lvdata] "Flatten to String" has "Expose Typedefs" right-click option

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

Hello,

I just learned that since LabVIEW 6.1 the "Flatten to String" function =
has a
right-click option called "Expose Typedefs".  I don't think that this
affects anything in (or if it is useful to) the LabVIEW Data Tools =
project,
but I just wanted to mention it.  From the LabVIEW Online Help...

__Flatten To String Details__
If you use this function to flatten a custom control that you saved as a
type definition, the function strips the type definition of its type
definition wrapper. If you do not want to strip a type definition =
control or
indicator of its wrapper, right the function and select __Expose =
Typedefs__
from the shortcut menu.

Notice that the "Variant to Flattened String" function doesn't have this
option.  To strip typedefs from a variant, you can call the lvdata VI
"Remove Typedefs from Variant.vi" which calls "Variant to Data" with a
Variant "type" argument.

-Jim

RE: [opengoop] Virtual Methods (Abstraction)

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

-=3D Re: encapsulation =3D-

After doing some reading, I realize that the object data is considered =
to be
"protected" if descendants can access it, but end users cannot.  End =
user's
only have access to the object vi (public) methods.  So, I guess it is =
OK
for descendants to access ancestor data.


-=3D Re: inheritable data structure =3D-

One problem that I have with the inheritable data structure is that =
since it
is "inside-out", descendants have to "dig" into the object data cluster =
in
order to get to the descendent data -- the more levels in the =
inheritance
hierarchy, the deeper they have to go.  This seems backwards, and =
confusing
to me.  I prefer digging into the object data cluster in order to get to
ancestor data.  Plus, descendents will normally be accessing the =
descendant
data, and not normally the ancestor data, so descendent data should be
easier to get to.

The only (but very useful) advantage of the inheritable data structure =
is
that a descendant data type will coerce to an ancestor data type, and
ancestor "downcasts" to descendant using "Variant to Data".  This has =
two
implications.

1) One does not have to bundle and unbundle data in "Class Get/Set Data =
as
Parent.vi", which means that there is no manual (or "scripting") task =
that
needs to occur in order to update the bundle/unbundle nodes when a data =
type
changes.  Note that "Bundle/Unbundle by Name" breaks when an element =
name
changes, and Bundle breaks when the number of elements changes (However,
Unbundle doesn't break when the number of elements changes).

2) Data could be stored in the oldest ancestor (root), rather than the
youngest descendant.  Does this have any advantages?  One, that I can =
think
of is that there will be no dynamic calls for accessing data.  However, =
does
this amount to much and how much overhead will there be if we are =
converting
to variant and back very often, anyway?

-=3D An alternative to the inheritable data structure =3D-

The change that we made to the inheritable data structure of wrapping =
the
{class added data} in a cluster, can also be applied to the standard
inheritance cluster, for a benefit that eliminates problem #1, above
(bundle/unbundle growth).

For example let's look at a Car's data cluster:
{Car Data} =3D=3D {{LandVehicle Data},{Car Added Data}}
Where:
{LandVehicle Data} =3D {{Vehicle Data}, {LandVehicle Added Data}}

Since each object's data is a cluster of exactly two subclusters, we can
bundle and unbundle (not by name) without worrying about the nodes =
growing
in size.  Therefore {Object Added Data} can grow in size without =
changing
the number of elements in {Object Data}.

I have posted an example of this on OpenG.org called "Strict Data
Inheritance Cluster".  The page is located at:

http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inheritance+C=
luste
r



-Jim




> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Jean-Pierre Drolet
> Sent: Tuesday, October 14, 2003 5:42 PM
> To: ope...@li...
> Subject: Re: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Ahh...
>=20
> I was sure you were talling about the "new" fact that an=20
> ancestor does have access to child data thru the introduced variant...
>=20
> The encapsulation issue also exists for embedded clusters=20
> datatypes. It may be possible for Class Get Data.vi to cast,=20
> unbundle and return only the class specific data. More easily=20
> with inheritance clusters since class specific data is=20
> bundled in a cluster. The problem I see actually is that the=20
> parent class isn't always aware when its data is accessed so=20
> it may be important that either a) the clild can't access=20
> parent data at all or b) it is allowed to modify it but all=20
> the ancestors Get/Set Data methods are invoked to notify that=20
> the data is accessed and modified. Maybe two methods can be=20
> used: Get/Set Class Data to access class specific data only=20
> and Get/Set Object Data to access all object data. In the=20
> latter, Get/Set methods are invoked for all classes to access data.
>=20
> It is also important for the object to have private data (not=20
> get/set outside the class) like internal state variables.=20
> These shouldn't be affected by get/set data operation on=20
> public variables. This private data need to be store in the=20
> object data space too.
>=20
>=20
>=20
> Jean-Pierre
>=20
>=20
> ----- Message d'origine -----=20
> De : "Jim Kring" <ji...@ji...>
> =C0 : <ope...@li...>
> Envoy=E9 : 13 octobre, 2003 22:23
> Objet : RE: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Jean-Pierre,
>=20
> Actually what I am talking about is the inverse.  I am not=20
> too concerned with an ancestor having access to descendant=20
> data, but rather I am concerned with a descendant having=20
> access to ancestor's private data.  Right now there is no=20
> distinction between private data and public data -- all=20
> object data is public.  Therefore, a class cannot protect=20
> itself from a descendant that doesn't fully understand its=20
> implementation (and descendants shouldn't have to=20
> understand).  Maybe there could be two types of data storage,=20
> public and private.  Public data would be accessible to the=20
> descendants, via their object data clusters, and private data=20
> would not be accessible to descendants.  Private data will=20
> not need an inheritance scheme since it is only available to=20
> one class-level.
>=20
> -Jim
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> SourceForge.net hosts over 70,000 Open Source Projects. See=20
> the people who have HELPED US provide better services: Click=20
> here: http://sourceforge.net/supporters.php
> _______________________________________________
> OpenGToolkit-Developers mailing list=20
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20

Re: [opengoop] Virtual Methods (Abstraction)

[Jean-Pierre D. <jea...@tr...>]

Ahh...

I was sure you were talling about the "new" fact that an ancestor does ha=
ve access to child data thru the introduced variant...

The encapsulation issue also exists for embedded clusters datatypes. It m=
ay be possible for Class Get Data.vi to cast, unbundle and
return only the class specific data. More easily with inheritance cluster=
s since class specific data is bundled in a cluster. The
problem I see actually is that the parent class isn't always aware when i=
ts data is accessed so it may be important that either a)
the clild can't access parent data at all or b) it is allowed to modify i=
t but all the ancestors Get/Set Data methods are invoked to
notify that the data is accessed and modified. Maybe two methods can be u=
sed: Get/Set Class Data to access class specific data only
and Get/Set Object Data to access all object data. In the latter, Get/Set=
 methods are invoked for all classes to access data.

It is also important for the object to have private data (not get/set out=
side the class) like internal state variables. These
shouldn't be affected by get/set data operation on public variables. This=
 private data need to be store in the object data space
too.



Jean-Pierre


----- Message d'origine -----=20
De : "Jim Kring" <ji...@ji...>
=C0 : <ope...@li...>
Envoy=E9 : 13 octobre, 2003 22:23
Objet : RE: [opengoop] Virtual Methods (Abstraction)


Jean-Pierre,

Actually what I am talking about is the inverse.  I am not too concerned
with an ancestor having access to descendant data, but rather I am concer=
ned
with a descendant having access to ancestor's private data.  Right now th=
ere
is no distinction between private data and public data -- all object data=
 is
public.  Therefore, a class cannot protect itself from a descendant that
doesn't fully understand its implementation (and descendants shouldn't ha=
ve
to understand).  Maybe there could be two types of data storage, public a=
nd
private.  Public data would be accessible to the descendants, via their
object data clusters, and private data would not be accessible to
descendants.  Private data will not need an inheritance scheme since it i=
s
only available to one class-level.

-Jim

Mailing list archive is now working

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

There was a problem with the list archive on SourceForge.net.  It is now
working and there are messages as far back as last Wednesday (way back ;-),
when the list was created.  You can access the list archives here...

http://sourceforge.net/mailarchive/forum.php?forum_id=35806

...or by going to the opengtoolkit project page on SF at...

http://sourceforge.net/projects/opengtoolkit

...and following the "Lists" link.

Cheers,

-Jim

RE: [opengoop] "Variant To Data" downcasts Class Type Inheritance Refnums

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

> In fact you used the technique yourself

Ah, yes :-))

-Jim

> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]=20
> On Behalf Of Jean-Pierre Drolet
> Sent: Monday, October 13, 2003 6:23 PM
> To: ope...@li...
> Subject: Re: [opengoop] "Variant To Data" downcasts Class=20
> Type Inheritance Refnums
>=20
>=20
> Jim,
>=20
> In fact you used the technique yourself in "EXAMPLE - Get Obj
> Info From Ref.vi" and that made me post the message about=20
> "Class Downcast to Self.vi". This VI should indeed check if=20
> the object is valid and return an error for invalid object=20
> even if the class downcast succeeds.
>=20
> Jean-Pierre
>=20
>=20
> ----- Message d'origine -----
> De : "Jim Kring" <ji...@ji...>
> =C0 : <ope...@li...>
> Envoy=E9 : 13 octobre, 2003 20:28
> Objet : [opengoop] "Variant To Data" downcasts Class Type=20
> Inheritance Refnums
>=20
>=20
> > Based on Jean-Pierre's comments about using "Variant to Data" for
> > downcasting an inheritable data structure, I realized that=20
> "Variant to
> > Data" can be used for downcasting Class Type Inheritance Refnums
> > (analagous to "To More Specific Class" fuction).  It will=20
> even output
> > an error at run-time (Error 91, "The data type of the
> variant is not
> > compatible with the data type wired to the type input."),
> if the class
> > information in the variant does not match the more specific
> type.  For
> > example, this prevents one from trying to Downcast to a
> class from the
> > classes uncle (Car =3D=3D> DeLorian is OK, but Truck =3D=3D>
> Delorian produces
> > an ERROR).  Adopting this technique means that a class does
> not have
> > to provide a polymorphic VI for downcasting to each
> descendant type.
> > The only downside, is that this method does not rely on the object
> > reference to check if the object is really of the more=20
> specific type.
> > However, this check will have to be done in any downstream VI that
> > operates on the more specific type.
> >
> > -Jim
> >
> >
>=20
>=20
>=20

RE: [opengoop] Virtual Methods (Abstraction)

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

Jean-Pierre,

Actually what I am talking about is the inverse.  I am not too concerned
with an ancestor having access to descendant data, but rather I am =
concerned
with a descendant having access to ancestor's private data.  Right now =
there
is no distinction between private data and public data -- all object =
data is
public.  Therefore, a class cannot protect itself from a descendant that
doesn't fully understand its implementation (and descendants shouldn't =
have
to understand).  Maybe there could be two types of data storage, public =
and
private.  Public data would be accessible to the descendants, via their
object data clusters, and private data would not be accessible to
descendants.  Private data will not need an inheritance scheme since it =
is
only available to one class-level.

-Jim



> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Jean-Pierre Drolet
> Sent: Monday, October 13, 2003 5:40 PM
> To: ope...@li...
> Subject: Re: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> Good point, Jim
>=20
> The variant is used as a placeholder for descendant data but=20
> still makes this data available for ancestors. Not only the=20
> data but also the data name and data type. That's indeed a=20
> big violation of encapsulation ( but great for a generic=20
> Read/Write Object to INI...).
>=20
> If we can't trust developpers not touching the variant child=20
> data ( it might be easy to rebundle data with empty or bad=20
> variant), then a solution could be that "Get Object Data.vi"=20
> get the class name from the incoming refnum and returns only=20
> the data relevant for this class (e.g. empty variant). That=20
> however adds complexity because the simple "Variant to Data"=20
> conversion has to be replaced with class analysis and variant=20
> data manipulation to access data. "Set Object Data.vi" would=20
> also replace only the data known by the calling class.
>=20
> My opinion is that added complexity would cancel the benefits=20
> of automatic upcasting by coercion and downcasting by=20
> "Variant to Data"
>=20
> Jean-Pierre
>=20
>=20
> ----- Message d'origine -----=20
> De : "Jim Kring" <ji...@ji...>
> =C0 : <ope...@li...>
> Envoy=E9 : 13 octobre, 2003 19:45
> Objet : Re: [opengoop] Virtual Methods (Abstraction)
>=20
>=20
> > Jean-Pierre,
> >
> > Should an OpenGOOP user who is developing a class, be given=20
> access to=20
> > the class's ancestors' data, at the bundle/unbundle node? =20
> Some people=20
> > would consider this to be a violation of encapsulation,=20
> since the user=20
> > can change ancestor data without going through the public interface=20
> > defined by the ancestor.  This could potentially allow a=20
> descentan to=20
> > break a parent's run- time characteristics. If all data in=20
> the class=20
> > hierarchy is not aggregated, then the issue of a class=20
> hierarchy data=20
> > structure is not important.
> >
> > -Jim
> >
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> SourceForge.net hosts over 70,000 Open Source Projects. See=20
> the people who have HELPED US provide better services: Click=20
> here: http://sourceforge.net/supporters.php
> _______________________________________________
> OpenGToolkit-Developers mailing list=20
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20