search

scala / pickling

Fast, customizable, boilerplate-free pickling support for Scala
lampwww.epfl.ch/~hmiller/pickling
BSD 3-Clause "New" or "Revised" License
831 stars 79 forks source link

StaticOnly should be used to choose the runtime strategy #418

Open jvican opened 8 years ago

jvican commented 8 years ago

Right now, we force the user to both select the runtime strategy and import StaticOnly so that only static picklers are used. However, the import StaticOnly should already decide to use one the runtime strategy that doesn't fallback to runtime generation when looking up tags. We may also want to add another implicit StaticOnlyWithLookup that will use the only-lookup runtime strategy.

Current limitation: the runtime strategy is defined in the package internal, that is initialized at boot time. As it's a top-level member, it can't depend on a user-imported implicit.

jsuereth commented 8 years ago

So, I have a few thoughts here:

  1. staticOnly is meant to be about the generated picklers themesleves. i.e. DO NOT use any reflection in the code generated for the picklers. (These should be scala-js friendly).
  2. Whether to delegate to runtime lookup of picklers should probably be a separate flag. I agree with you that it should be controlled. By default, i think picklers are designed to be in "hybrid" form where you can lookup picklers at runtime, but prefer to generate static picklers. BUT the user should be able to (easily) turn that off and force all static-types everywhere, including the gymnastics involved in figuring out these types on both sides of a communication channel.

So basically, I'm ok adding a RuntimeLookup flag with NoRuntimeLookup as something that can be imported in-tandem with StaticOnly. I can also update the docs to reflect this if you think it's a good idea.