refactor type handling

[tnagler]

No description provided.

[codecov]

Codecov Report

Attention: Patch coverage is 97.60000% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 96.12%. Comparing base (d8f98d9) to head (18eeb9e).

❗ Current head 18eeb9e differs from pull request most recent head 8eaaa88

Please upload reports for the commit 8eaaa88 to get more accurate results.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #17      +/-   ##
==========================================
+ Coverage   94.98%   96.12%   +1.13%     
==========================================
  Files           6        6              
  Lines         678      774      +96     
==========================================
+ Hits          644      744     +100     
+ Misses         34       30       -4     

Files	Coverage Δ
include/kde1d/kde1d.hpp	97.81% <97.60%> (+1.51%)	⬆️

... and 2 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d8f98d9...8eaaa88. Read the comment docs.

[tvatter]

Internally, I think that type should be stored as an enum and that there should be two constructors : one for string with standardiye_type and one for the enum. Otherwise, LGTM.

[tnagler]

Internally, we could use an enum class for safety reasons, but having two constructor versions feels a bit unnecessary. I'd vote for enum internally, string externally (also with py interface in mind).

[tvatter]

Internally, I think that it goes without saying. Externally (i.e., for the constructor), I'd argue for the enum too, as it is what we do in vinecopulib for the families. Now that you mention it, it is clearly clunky (and borderline nonpythonic) in pyvinecopulib, but for the C++ code, I believe that it's the right thing to do.