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 ;-)

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.

> I think that there's a bit of OOness that could be applied to your code
> here.

yes - probably.  funny you should mention really - i've been thinking about
this set of classes alot.  the snippets are from a class hierarchy that has
about 50 classes already, with lots of inheritence.  i started out making
classes for attributes and backed off - probably because i have about 30
classes that generate commands, each with 20-40 attributes and the 'attribute
classes' are not easy to auto-generate or share code via modules/inheritence.
in any case i've got plenty of other classes in there doing classy types of
things...  so - this code has been in production for a while and i'm finding
any of the classes hard to change - i used inheritence too much (i'm starting
to think 'at all' == 'too much') i think.  anyhow, my current style is moving
back towards lots of hashes  and fewer classes because it ends up being much
easier to change or break depending on your perspective, but remember i'm in a
research environment where absolutely NOTHING is stable for > week.  in
summary i find a 'good' class design to be more important for languages that
are hard to debug - but less so for ruby.  i think this is backwards from what
most people are finding - that ruby encourages good class design.  in some
ways i think it does because doing good design is possible so easily, but
coding and debugging is also relatively effortless temping me to be a bit more
lax in the design phase...

thought you might find that interesting.

-a
--
===============================================================================
| EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE   :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself.  --Shunryu Suzuki
===============================================================================