From: Austin Ziegler Date: 2004-11-02T10:23:38+09:00 Subject: Re: [OT] Re: Another scrach on head On Tue, 2 Nov 2004 10:14:00 +0900, ara.t.howard@noaa.gov wrote: > On Tue, 2 Nov 2004, Austin Ziegler wrote: >> This is because the "if solar_elev_file" test would fail if it >> were false. Perhaps your test would have better been "unless >> solar_elev_file.nil?" :) > > ah yes - that bug is actually fixed in a bunch of similar code - > in reality it has no effect since having 'solar_elev_file=0' in > the command is the same as not having it, but it's a bug > nonetheless... good catch for just reading email though! :) >> Using the class, it would be: >> >> def solar_elev_file=(value) >> @solar_elev_file = SolarElevFile.new(value) >> end >> >> def solar_elev_file >> @solar_elev_file >> end >> >> ... >> >> def gen_command >> command = "%s,'%s','%s" % [ program, olsfile, flagfile ] >> ... >> command << solar_elev_file.to_s if solar_elev_file >> ... >> end > which, lol, fails for the same reason as my code ;-) Actually, not at all. By using SolarElevFile, the value of #solar_elev_file will either be +nil+ or an instance of SolarElevFile. Thus, it uses Ruby's normal boolean test behaviour and does exactly what it's supposed to... > i __do__ like your AttributeClass approach though. i'd quickly > have > > BooleanAttributeClass < AttributeClass > StringAttributeClass < AttributeClass > FloatAttributeClass < AttributeClass > > etc. essentially mappings of many ruby types to one idl type... > food for thought. Well, it's usable for that. -austin -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca : as of this email, I have [ 5 ] Gmail invitations