Passing lots of parameters in SPIN2

kolyur

I'm a SPIN1 user who's delving into SPIN2, although this question probably applies to both. I'm creating some objects to reduce the complexity of my top level program. The problem is that the objects will need to read and write a lot of variables from the top level. I know this issue has been discussed a lot in the forum but I feel like I'm missing something. Creating methods with dozens of arguments just to pass data seems like a kludge. The best way I can think of is to declare all the top level variables in the DAT section so they will be consecutively mapped, then pass the address of the first one to the object. There are a variety of long/word/byte sized variables so the object would have to be hard coded to match the DAT layout. Additionally, a number of the variables are arrays that have differing lengths specified by constants set elsewhere. Somehow I would also need to pass the sizes of the arrays so that I can correctly assign the data to matching local variables/arrays in the child object. This seems like it should be a more straightforward process and I'm a bit overwhelmed. Any suggestions?

Wuerfel_21

If moving a function into an object is as complicated as you describe, it should either stay in the top object or you should move the associated variables into the sub-object, too. Do not move anything into a sub-object just to have it in a separate file. (Possible exception: Objects that are 99% DAT or CON)

JonnyMac

I agree with Ada: if your methods will be operating on a lot of variables in the parent, keep the code that does that in the parent.

There are times when you need to pass a lot of parameters to a child object -- usually for configuration. In that case I tend to pass a pointer to the first of a list of variables/DAT values (note that them must by the same size). Here's an example:

dat { pin groups }

  AudioPins     long    SD_DO, SD_CLK, SD_DI, SD_CS
                long    A_SYNC, A_SCLK, A_DATA
                long    -1                                      ' no mute pin

  LedPins       byte    MUZL_R, MUZL_G, MUZL_B
                byte    HIT_R, HIT_G, HIT_B
                byte    LCD_BL, $FF

The first set of pins is for the WAV player cog, the second is for a PWM driver.

Here's the entry into the WAV player -- as you can see, it expects a pointer and knows what to do from there.

pub start(p_pindefs)

'' Start WAV playback cogs
'' -- p_pindefs is pointer (array of longs)

evanh

I've ended up with one object that uses a prefilled table of pointers. This was to allow independent later read-only queries to be filled without generating any overheads in the tasks of the objects being queried. It also allowed queries into multiple objects. Yes, the reader object is then coded to assume the variable type at each address.