comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: How to traverse/inquire a class object structure in IDL?
items: Re: How to traverse/inquire a class object structure in IDL?

How to traverse/inquire a class object structure in IDL?
type: item
description: Hello, Last night I entered into the world of IDL objects. I was amazed at how much easier it is to keep control of a data object rather than using a regular structure. Anyway, since I have been programming IDL in an Object Oriented mode for about 8 hours, I have some questions that I hope someone out there can help me with. The documentation (on-line and printed) was not useful. I have a class structure definition in nasti__define.pro: PRO nasti__define, nasti_structure ; -- Define the data structure nasti_structure = { NASTI, $ wavenumber : PTR_NEW(), $ radiance : PTR_NEW(), $ altitude : PTR_NEW(), $ fov_angle : PTR_NEW(), $ fov_index : PTR_NEW(), $ latitude : PTR_NEW(), $ longitude : PTR_NEW(), $ aircraft_roll : PTR_NEW(), $ aircraft_pitch : PTR_NEW(), $ scan_line_index : PTR_NEW(), $ date : PTR_NEW(), $ time : PTR_NEW(), $ decimal_time : PTR_NEW() } END which will eventually contain an aircraft instrument data time series of unknown length - hence the pointers. I create the object: IDL> n=OBJ_NEW( 'nasti' ) and read in some data from a netCDF file (only the first data structure field, wavenumber, is filled for now): IDL> print, n->read_nasti( ncdf_filename ) This all works fine. I have an simple inquire method: PRO nasti::inquire_nasti PRINT, FORMAT = '( /5x, "Inquiring..." )' PRINT, PTR_VALID(), OBJ_VALID() END which when I run it, gives: IDL> n->inquire_nasti Inquiring... <PtrHeapVar2> <ObjHeapVar1(NASTI)> where the PtrHeapVar2 is the pointer to "self.wavenumber" and the object reference is for the object. Cool. I assumed that if I destroyed the object, the pointer references would still be there, dangling away, which turns out to be true: IDL> obj_destroy, n IDL> print, ptr_valid(), obj_valid() <PtrHeapVar2> <NullObject> Not good. As more objects are created and destroyed, the valid pointer list grows. I would like to do the following in a CLEANUP method: FOR i = 0, n_object_structure_elements - 1 DO $ IF ( PTR_VALID( self.(i) ) ) THEN $ PTR_FREE, self.(i) th…
creator: Paul van Delst
date: 1999-10-13T07:00:00-00:00

Re: How to traverse/inquire a class object structure in IDL?
type: item
description: Paul van Delst wrote: > > First off, thanks to David and Pavel for their insights. Before I could check the > newsgroup for replies, one of our younger go-getter science types came and told me > something about object oriented programming that made good sense: > > The data should be an attribute of the object, not the object itself. > > Hmm. Anyway, he and I sat down for about 15 minutes and came up with the following > class structure definition and cleanup method: > > PRO nasti__define > > ; -- Define the NAMED data structure attribute > data = { data, $ > wavenumber : PTR_NEW(), $ > radiance : PTR_NEW(), $ > altitude : PTR_NEW(), $ > fov_angle : PTR_NEW(), $ > fov_index : PTR_NEW(), $ > latitude : PTR_NEW(), $ > longitude : PTR_NEW(), $ > aircraft_roll : PTR_NEW(), $ > aircraft_pitch : PTR_NEW(), $ > scan_line_index : PTR_NEW(), $ > date : PTR_NEW(), $ > time : PTR_NEW(), $ > decimal_time : PTR_NEW() } > > ; -- Create object CLASS structure > nasti = { nasti, $ > data : data } > > END > > I like this becuase now I can add additional attributes whenever I want, e.g. > global attribute data read from the netCDF data file containing instrument > calibration information and/or processing software CVS/RCS info etc. > > The cleanup method is now: > > PRO nasti::cleanup > > PRINT, FORMAT = '( /5x, "Clean up..." )' > > ; -- Free up pointers > n_data_fields = N_TAGS( self.data ) > FOR i = 0, n_data_fields - 1 DO $ > IF ( PTR_VALID( self.data.(i) ) ) THEN $ > PTR_FREE, self.data.(i) > > END > > I just couldn't bring myself to typing PTR_FREE, self.whatever a bunch of times > because if I ever change the data structure definition, I would have to change the > cleanup as well. I like changes in my code to have as small a footprint as > possible, i.e. change is required in as few places as possible. Dunno if that's a > great idea but for my simple little example but it's a start. Right? > > I wish I'd "discovered" objects earlier......all that code I wrote that *needs* the > …
creator: J.D. Smith
date: 1999-10-15T07:00:00-00:00