comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: Re: Object Blues

Re: Object Blues
type: item
description: mirko_vukovic@notes.mrc.sony.com wrote: > > In article <34BFBBD7.B8EC1D48@astrosun.tn.cornell.edu>, > "J.D. Smith" <jdsmith@astrosun.tn.cornell.edu> wrote: > stuff deleted ... >> The second complaint is that IDL classes are not permitted to define >> public data members. That is, you can't access "someObject.somedata" >> anywhere outside that objec'ts own methods. Perhaps RSI saw the >> exclusion of this feature as a simplifying decision, and one that >> guarantees encapsulation. Indeed, limiting object access to its method >> procedures and functions may, at first thought, seem an obvious way to >> keep object code well-contained. However, it has other unfortunate >> consequences, usually related to the need to acquire a small group of >> parameters from an object for extensive and repeated use. The only >> solution within the current context is a GetProperty method (which, as >> you may recall, is hampered by the non-reference passing of inherited >> keywords). This is the solution implemented by IDL's object graphics. >> I maintain that an object method (such as most of the GetProperty's) >> which simply returns some subset of the member data without any >> pre-processing is wasteful and inelegant, and that the true power of >> encapsulation is in the ability to select which parts of an object to >> encapsulate. > more stuff deleted ... > > jd, > > the way I work on this is to have a helper object defined, name 'obj'. > This object has a method GetProperty. If I want to get a property of > some object, I have it inherit 'obj'. These days as a matter of routine > I have all my non-base objects inherit 'obj'. > > 'OBJ' could be expanded to include a field 'public'. This would be a > string array that would specify an objects public members. GetProperty > would check on that prior to returning the property. > > This does not look terribly inconvenient. This solution is basically the one that RSI uses for its object graphics routines. Subclassing makes it slightly ea…
creator: J.D. Smith
date: 1998-01-20T08:00:00-00:00

Re: Object Blues
type: item
description: Mirko Vukovic (mirko_vukovic@notes.mrc.sony.com) supplies some excellent advice. Then he writes: > on the other hand, can you expand on your xmanager problem? I recently > wrote my first widget routine, and promptly dispensed with xmanager using > widget_event instead. But I am still wondering how foolish I may have > been. Whoa, whoa, whoa. Hold on right there, Mirko! This is a road you do NOT want to be taking. I'm putting a book in the mail to you this afternoon. Send it back to me if you don't find it ENORMOUSLY helpful. :-) Cheers, David ----------------------------------------------------------- David Fanning, Ph.D. Fanning Software Consulting E-Mail: davidf@dfanning.com Phone: 970-221-0438 Coyote's Guide to IDL Programming: http://www.dfanning.com/
creator: davidf
date: 1998-01-20T08:00:00-00:00

Re: Object Blues
type: item
description: In article <34BFBBD7.B8EC1D48@astrosun.tn.cornell.edu>, "J.D. Smith" <jdsmith@astrosun.tn.cornell.edu> wrote: stuff deleted ... > The second complaint is that IDL classes are not permitted to define > public data members. That is, you can't access "someObject.somedata" > anywhere outside that objec'ts own methods. Perhaps RSI saw the > exclusion of this feature as a simplifying decision, and one that > guarantees encapsulation. Indeed, limiting object access to its method > procedures and functions may, at first thought, seem an obvious way to > keep object code well-contained. However, it has other unfortunate > consequences, usually related to the need to acquire a small group of > parameters from an object for extensive and repeated use. The only > solution within the current context is a GetProperty method (which, as > you may recall, is hampered by the non-reference passing of inherited > keywords). This is the solution implemented by IDL's object graphics. > I maintain that an object method (such as most of the GetProperty's) > which simply returns some subset of the member data without any > pre-processing is wasteful and inelegant, and that the true power of > encapsulation is in the ability to select which parts of an object to > encapsulate. more stuff deleted ... jd, the way I work on this is to have a helper object defined, name 'obj'. This object has a method GetProperty. If I want to get a property of some object, I have it inherit 'obj'. These days as a matter of routine I have all my non-base objects inherit 'obj'. 'OBJ' could be expanded to include a field 'public'. This would be a string array that would specify an objects public members. GetProperty would check on that prior to returning the property. This does not look terribly inconvenient. on the other hand, can you expand on your xmanager problem? I recently wrote my first widget routine, and promptly dispensed with xmanager using widget_event instead. But I am still wondering how foolish I ma…
creator: mirko_vukovic
date: 1998-01-20T08:00:00-00:00