You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several packages in this repo are providing function wrappers (aka factory functions) for class constructors and their use is the preferred public API (though not enforced). E.g.
In the simplest (and the most) cases, these wrappers merely act as syntax sugar for new ClassName(...), but sometimes also do more prep work WRT to given options. The current naming convention is that these function wrappers are (usually) a lowercase-initial version of their respective class names. This is very useful to "denoise" nested cases as well as to simplify class instantiations in a FP context/pipeline...
Adding the prefix def to such function wrapper names is another pattern I've been using increasingly. This is inspired by Clojure nomenclature and maybe better expresses the intent of these functions (i.e. to "define" something). The current uses of that naming convention are not exclusively class ctor wrappers, but more generally reserved for any uses of that nature (i.e. some form of object creation / initialization, no necessarily class based).
Since there's been some potential confusion about the (too similar?) naming of the other approach above (i.e. shader() vs. new Shader()), I'm looking for some feedback about starting to the use defXXX() convention more extensively, incl. renaming some (not all!) of the existing factory fns.
// some thi.ng/webgl examples:shader()->defShader()compileModel()->defModel()texture()->defTexture()fbo()->defFbo()
I believe for some packages (e.g. rstream), the existing naming (w/o def) works very well and so I don't think that new naming convention should become dogma, but treated as preferential.
Several packages in this repo are providing function wrappers (aka factory functions) for class constructors and their use is the preferred public API (though not enforced). E.g.
In the simplest (and the most) cases, these wrappers merely act as syntax sugar for
new ClassName(...)
, but sometimes also do more prep work WRT to given options. The current naming convention is that these function wrappers are (usually) a lowercase-initial version of their respective class names. This is very useful to "denoise" nested cases as well as to simplify class instantiations in a FP context/pipeline...Adding the prefix
def
to such function wrapper names is another pattern I've been using increasingly. This is inspired by Clojure nomenclature and maybe better expresses the intent of these functions (i.e. to "define" something). The current uses of that naming convention are not exclusively class ctor wrappers, but more generally reserved for any uses of that nature (i.e. some form of object creation / initialization, no necessarily class based).Since there's been some potential confusion about the (too similar?) naming of the other approach above (i.e.
shader()
vs.new Shader()
), I'm looking for some feedback about starting to the usedefXXX()
convention more extensively, incl. renaming some (not all!) of the existing factory fns.I believe for some packages (e.g. rstream), the existing naming (w/o
def
) works very well and so I don't think that new naming convention should become dogma, but treated as preferential.I'm very aware that this (like anything stylistic) is always gonna be highly subjective, but nevertheless, any thoughts on this are very appreciated!
The text was updated successfully, but these errors were encountered: