Many or few constructor signatures?

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 ].