Problem with srr slot when sharing saved params objects

[gustavdelius]

The fact that the params object has a slot that contains a function creates a problem when we save params objects to disk and then share them with each other. To see this, take a look at the stock recruitment function stored in the @srr slot of one of the params objects that Ken recently added to mizer:

Barents_params@srr

This produces:

<srcref: file "/Users/ken/Documents/Source/Mizer/R/MizerParams-class.R" chars 2391:20 to 2396:1>
<environment: namespace:mizer>
Warning messages:
1: In getSrcLines(srcfile, x[7L], x[8L]) :
  restarting interrupted promise evaluation
2: In getSrcLines(srcfile, x[7L], x[8L]) :
  internal error -3 in R_decompress1

Notice that it points to code on Ken's computer and hence R produces some cryptic warning messages.

Note also that the @srr slot contains a closure (http://adv-r.had.co.nz/Functional-programming.html#closures), i.e., it contains its environment, which in this case is the entire content of the mizer namespace. I don't know if that is a problem, because I have not really gotten my head around closures. But it sounds like it might be a problem when sharing params objects. It does for example lead to inflated file sizes when saving the params objects to disk.

The easiest way to avoid these complications is to not store the function in the @srr slot but instead a string with the name of the function. This would be similar to how we currently specify the gear selectivity functions and the predation kernel type.

Another option would be to take the option of using alternative stock-recruitment relationships out of the main mizer package and provide it via a mizer extension and in the process design it more carefully.

Both these options would break backwards compatibility, but I don't think many people have used alternative stock-recruitment relationships yet.

All comments welcome.

[Kenhasteandersen]

The easiest way to avoid these complications is to not store the function in the @srr slot but instead a string with the name of the function. This would be similar to how we currently specify the gear selectivity functions and the predation kernel type. I vote for this option. It is simple and it is in line with how with specify gears. I don’t worry about breaking compatibility, because I don’t think the option has been used. Ken Another option would be to take the option of using alternative stock-recruitment relationships out of the main mizer package and provide it via a mizer extension and in the process design it more carefully. Both these options would break backwards compatibility, but I don't think many people have used alternative stock-recruitment relationships yet. All comments welcome. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#91?email_source=notifications&email_token=ADFHLANXOYEFGSPG7MFKJ43QJSIAPA5CNFSM4IWWHWG2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HLLVJ6Q>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADFHLALZHTZ6OHCSEU7YO5LQJSIAPANCNFSM4IWWHWGQ>.

[gustavdelius]

Thanks @Kenhasteandersen, I will go ahead and implement that solution now.