comp.lang.idl-pvwave archive: archive » IDL 8.0 compile

Home » Public Forums » archive » IDL 8.0 compile_opt changes

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Re: IDL 8.0 compile_opt changes [message #69333 is a reply to message #69187]

Tue, 05 January 2010 14:41

JDS
Messages: 94
Registered: March 2009

Member

While I long ago converted to [] for array subscripting for the
reasons most succinctly expressed by Wayne, I have mixed feelings
about converting the method invocation operator from '->' to '.'
purely for cosmetic reasons. Problems I see with this:

1. Overloading structure dereference and method invocation breaks the
ability to semantically parse a.b.

With this overloading, it is impossible to determine if 'a.b' is a
method procedure call, or a structure field dereference, *except at
runtime in the IDL interpreter*! For example, in IDLWAVE you can a->b
[M-Tab] and have all "b..." procedure methods completed, or c=a->b[M-
Tab] for function methods. Though I'm not sure, I suspect this would
have a similar impact on the Workbench: loss of edit-time or shell-
interaction-time differentiation among structure fields/object methods/
etc through direct inspection of the source.

2. It will *not* be immediately obvious, or *ever* obvious, to a human
observer that code which includes statements like a.b(c) must be
compiled with IDL8.0 to run correctly. Consider a simple function
found deeply buried on disk:

function do_something, input
return, input.something_else(1)
end

This small function would compile equally in IDL 8 and IDL <8, but
have a totally different meaning depending on what INPUT was passed in
which version. You can make compile_opt idl2 the default in IDL 8,
but this does little to relieve this issue, since older versions of
IDL will compile this fine (and choke horribly if passed an object).

3. IDL is not Python. IDL enforces strict encapsulation of object
data, i.e. all object data must be accessed through a method (except
within the object's methods themselves). Python has no object data
encapsulation. In Python it is natural to mix method invocation with
data access. In IDL this only occurs only in an object's own
methods. Which is clearer?

self->limit, self.limit

self.limit, self.limit

Just my $1D-2. (BTW, I think negative indexing sounds great!).

JD

Report message to a moderator

[Message index]

		IDL 8.0 compile_opt changes By: chris_torrence@NOSPAM on Fri, 18 December 2009 13:51
		Re: IDL 8.0 compile_opt changes By: wlandsman on Mon, 28 December 2009 04:36
		Re: IDL 8.0 compile_opt changes By: penteado on Sun, 27 December 2009 19:44
		Re: IDL 8.0 compile_opt changes By: H. Evans on Sat, 26 December 2009 13:21
		Re: IDL 8.0 compile_opt changes By: alt on Fri, 25 December 2009 02:30
		Re: IDL 8.0 compile_opt changes By: penteado on Thu, 24 December 2009 08:49
		Re: IDL 8.0 compile_opt changes By: wlandsman on Thu, 24 December 2009 05:07
		Re: IDL 8.0 compile_opt changes By: David Fanning on Thu, 24 December 2009 03:44
		Re: IDL 8.0 compile_opt changes By: penteado on Wed, 23 December 2009 22:13
		Re: IDL 8.0 compile_opt changes By: David Fanning on Wed, 23 December 2009 20:48
		Re: IDL 8.0 compile_opt changes By: proffmw@gmail.com on Wed, 23 December 2009 20:08
		Re: IDL 8.0 compile_opt changes By: penteado on Wed, 06 January 2010 10:35
		Re: IDL 8.0 compile_opt changes By: JDS on Fri, 08 January 2010 13:42
		Re: IDL 8.0 compile_opt changes By: Matt[2] on Wed, 06 January 2010 08:18
		Re: IDL 8.0 compile_opt changes By: Yngvar Larsen on Wed, 06 January 2010 07:29
		Re: IDL 8.0 compile_opt changes By: David Fanning on Wed, 06 January 2010 07:13
		Re: IDL 8.0 compile_opt changes By: Yngvar Larsen on Wed, 06 January 2010 07:12
		Re: IDL 8.0 compile_opt changes By: Kenneth P. Bowman on Wed, 06 January 2010 06:52
		Re: IDL 8.0 compile_opt changes By: Yngvar Larsen on Wed, 06 January 2010 06:56
		Re: IDL 8.0 compile_opt changes By: Michael Galloy on Wed, 06 January 2010 13:52
		Re: IDL 8.0 compile_opt changes By: Maarten[1] on Wed, 06 January 2010 06:01
		Re: IDL 8.0 compile_opt changes By: Michael Galloy on Wed, 06 January 2010 13:25
		Re: IDL 8.0 compile_opt changes By: penteado on Tue, 05 January 2010 15:54
		Re: IDL 8.0 compile_opt changes By: JDS on Tue, 05 January 2010 14:41
		Re: IDL 8.0 compile_opt changes By: Paul Van Delst[1] on Thu, 07 January 2010 08:35
		Re: IDL 8.0 compile_opt changes By: monkman on Tue, 05 January 2010 13:51
		Re: IDL 8.0 compile_opt changes By: David Fanning on Tue, 05 January 2010 11:17
		Re: IDL 8.0 compile_opt changes By: chris_torrence@NOSPAM on Tue, 05 January 2010 10:58
		Re: IDL 8.0 compile_opt changes By: chris_torrence@NOSPAM on Tue, 05 January 2010 10:57
		Re: IDL 8.0 compile_opt changes By: pgrigis on Tue, 05 January 2010 06:57
		Re: IDL 8.0 compile_opt changes By: R.Bauer on Tue, 05 January 2010 06:09
		Re: IDL 8.0 compile_opt changes By: David Fanning on Mon, 04 January 2010 11:58
		Re: IDL 8.0 compile_opt changes By: chris_torrence@NOSPAM on Mon, 04 January 2010 11:41
		Re: IDL 8.0 compile_opt changes By: R.Bauer on Mon, 04 January 2010 02:30
		Re: IDL 8.0 compile_opt changes By: Jeremy Bailin on Tue, 29 December 2009 21:31
		Ruby range operators? Re: IDL 8.0 compile_opt changes By: Paul Van Delst[1] on Fri, 08 January 2010 13:16
		Re: IDL 8.0 compile_opt changes By: penteado on Fri, 08 January 2010 05:36
		Re: IDL 8.0 compile_opt changes By: Maarten[1] on Fri, 08 January 2010 04:19
		Re: IDL 8.0 compile_opt changes By: H. Evans on Fri, 08 January 2010 01:29
		Re: IDL 8.0 compile_opt changes By: Michael Galloy on Thu, 07 January 2010 09:56
		Re: IDL 8.0 compile_opt changes By: Maarten[1] on Thu, 07 January 2010 07:27
		Re: IDL 8.0 compile_opt changes By: wallabadah on Wed, 06 January 2010 16:30

Previous Topic:	Re: envi_title_bar.ico missing and null pointer dereferenced error when using .sav file in ENVI
Next Topic:	A routine to annotate PS files

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Fri Oct 10 03:29:27 PDT 2025

Total time taken to generate the page: 0.31873 seconds