Re: Eleven more Heatbugs questions...

[Ken Cline]

On Tue, 29 Jul 1997 address@hidden wrote:

> In heatbug.m:
> 
> 1) Are "world" and "heat" objects?

Yes.  Technically, these (instance) variables are pointers
to objects.  From Heatbug.h:
     Grid2d * world;            // the world I live in
     HeatSpace * heat;          // the heat for the world

So "world" is a pointer to a "Grid2d" object and "heat" is a
pointer to a "HeatSpace" object.


> 2) What does this line do:
> [heat findExtremeType: (heatHere <idealTemperature) ? hot : cold X:
> &newX Y: &newY];
> Mostly, I'm interested in what the part "(heatHeare....? hot : cold
> X:..." does and how to interpete it.


"(heatHere <idealTemperature) ? hot : cold"

Okay, here they are using the C ternary operator "?:".  The
ternary operator is C shorthand for "if-then-else" and is
meant to be used (like above) inside a function call.

For example, the following are equivalent:

   if ( x < 0 )
      printf( "negative" );
   else
      printf( "positive" );

and

   printf( "%s", ( (x < 0) ? "negative" : "positive" ) );
 

> 3) Is uniformDblRand a type or class?

"uniformDbleRand" is (a pointer to) an instance of the
"UniformDouble" class.  This would have been a little hard
to find... it is a "external" variable defined in the
<simtools.h> file.  This file was "#import"-ed at the top of
the Heatbug.m file.  Note:
   % pwd
   /opt/proj/swarm/SWARMHOME/src

   % grep uniformDblRand */*.h */*.m | more
     simtools/global.h:extern id <UniformDouble> uniformDblRand;
        ...


> 4) (silly question) When in a method call like: "-setOutputHeat:
> (HeatValue) o {...", does (HeatValue) cast the "o" or is it a impromtu
> declaration of a local type?

Well, it depends...  You are referring to the method
declaration in Heatbug.m, or the method definition in
Heatbug.h, I presume.  In these cases, "(HeatValue)" tells
the compiler that data type of the argument to
"setOutputHeat" is "HeatValue".  "HeatValue" is a defined
type, see HeatSpace.h:

      typedef int HeatValue;

that is, it is equivalent to an int.  This wasn't done
sadistically to confuse newbies, btw.  The purpose is to
abstract the HeatValue type.  The idea is to make no
assumptions about HeatValue except that it a numeric type.
If extra percision is required for some reason in the
future, then changing the above line to something like:

      typedef double HeatValue;

should be all that's required.

Now, in the following situation, you could use "HeatValue"
to cast:

      float f = 1.111

      ...

      [ myBug setOutputHeat: (HeatValue) f ];

The difference here is that this is a method call and types.
such as "HeatValue" are only put in method calls when
casting.  BTW, putting casting in method calls is good
practice/style, even if its not really needed, because it
eliminates potential confusion/errors.  For example, if I
had written:
      [ myBug setOutputHeat: f ];
the value would probably have been *implicitly* cast.

> 5) I'm still a little confused about the "Bug" and "aBug"
in graphBug:?

-graphBug: aBug {
  [unhappyGraph createSequence: "Bug"
                  withFeedFrom: aBug
                   andSelector: M(getUnhappiness)] ;
 
  return self ;
}

Okay, here we have some *implicit* type-ing... a little
confusing, eh?

The default return type of any function is "id".  The
default argument type is also "id" (apparently). That is,
the following is an equivalent definition of "graphBug":

      -(id) graphBug: (id) aBug {
          ...
      }

So, "aBug" is an id-pointer (ie void *) that should point to
an instance of the Heatbug class.  If you wanted to strongly
type your methods, you could rewrite the method like:

      -(id) graphBug: (Heatbug *) aBug {
          ...
      }

Now, "graphBug" can only be called with a pointer to an
instance of Heatbug.  The compiler will try to check this is
true at compile time, but may not be able to insure that
this is always going to be true.  If, at runtime, something
other that an instance of Heatbug is passed then the
strongly typed version of the graphBug method will abort.


_________________________________________________________
Ken Cline                             address@hidden
SAIC                                 VOICE (410) 571-0413
Annapolis, MD                          FAX (301) 261-8427




                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================