Is there a best practice with respect to construction, now that construction is separate from conversion and seems to be more taxonomically essential? Some have recommended that a family of constructors for a user-defined struct be as thin as is reasonable. Others prefer the direct action that obtains with construction over multi-signatures.
I have two, related, questions regarding best perspective to bring in polyphonic construction using Julia’s constructor_of_this_is_its_own_name multidispatching realization. The first is an attempt to clarify the river that flows through our most modern construct & convert dyadic. The second is a grasp at best practice in the design, care & feeding of constructors we etch.
My current understanding is that this is the grist with which Julia mills artistry from effortstry: construction manufactures and multi-realizes while conversion serves as the enactor of promotion and provides the provable in dataform adaption.
When deriving a close-kint family of constructors or sculpting relatably given constructions, some essential guidance is to come from the way Julia just works and improves our workpersonhood. I am comfortable with that … please allow your insight to hone the way we confer the best practices to others.
1 Like
This may not be new (since you participated in the topic), but
has a lot of good advice for constructors.
I would not worry about too many outer constructor methods per se, eg DataFrames.DataFrame has 16 outer methods (and 1 inner constructor).
However, if you need more than a few (ideally 1) inner constructors (eg for validation), you may be doing something wrong.
1 Like
Thanks for referencing me to me [ Julia really is grand ].