Currently, arguments to user-facing functions are an awkward mixture of camelCase names and underscore_names. These should all be changed to using underscores, and shortened where possible. Additionally, there are a couple of methods whose arguments are reversed compared to what they should be (such as Crystal()). These should all be changed for consistency. I'd like to break everything at once to avoid the pain of repeatedly breaking the API. Once version 1 is released, that version will have a stable API (except with the potential addition of keyword arguments).
Here is a proposed set of standard arguments:
er: permittivity or permittivity data
ur: permeability or permeability data
n: refractive index or refractive index data
source: Excitation source
crystal: anywhere a member of the Crystal() class is to appear
material: anywhere a member of the Material() class is to appear
n_harmonics: Number of harmonics to use
nx, ny, nz: Any time a number is required along one of these axes
xmin, xmax, ymin, ymax, zmin, zmax
thickness: For layer thicknesses. "t" and "L" are ambiguous, and "L" makes even less sense than "t"
Some other random todos:
get rid of "generate" in function names
Add underscores at the beginning of all class methods not intended to be exposed to public API
Explicitly pass in reflection and transmission region layers rather than relying on position
Allow seamless use of LayerStacks in other LayerStacks rather than only passing in layers - extract the undrelying layers at runtime
The current way the Solver exposes results is really ugly, and makes it time-consuming to grab data.
edmundsj
commented
2 years ago
Currently, arguments to user-facing functions are an awkward mixture of camelCase names and underscore_names. These should all be changed to using underscores, and shortened where possible. Additionally, there are a couple of methods whose arguments are reversed compared to what they should be (such as Crystal()). These should all be changed for consistency. I'd like to break everything at once to avoid the pain of repeatedly breaking the API. Once version 1 is released, that version will have a stable API (except with the potential addition of keyword arguments).
Here is a proposed set of standard arguments:
Some other random todos: