Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[all] RFC: Factory function naming convention #210

Closed
postspectacular opened this issue Mar 9, 2020 · 0 comments
Closed

[all] RFC: Factory function naming convention #210

postspectacular opened this issue Mar 9, 2020 · 0 comments

Comments

@postspectacular
Copy link
Member

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.

const foo = stream<number>();
// vs.
const bar = new Stream<number>();

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

// create 5 streams
const [a, b, c, d, e] = repeatedly(stream, 5);
// vs
const [a, b, c, d, e] = repeatedly(() => new Stream(), 5);

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.

// existing naming
stream().subscribe(sidechainPartition(...)).subscribe(tunnel(...))
// vs
defStream().subscribe(defSidechainPartition(...)).subscribe(defTunnel(...))

I'm very aware that this (like anything stylistic) is always gonna be highly subjective, but nevertheless, any thoughts on this are very appreciated!

postspectacular added a commit that referenced this issue Mar 28, 2020
- add defArraySet()
- add defLLSet()
- add defSortedSet()
- add defSparseSet()
- add defEquivMap()
- add defHashMap()
- add defSortedMap()

BREAKING CHANGE: remove static `fromObject()` map factories

- merged with defHashMap(), defSortedMap()
postspectacular added a commit that referenced this issue Mar 28, 2020
BREAKING CHANGE: #210, rename factory functions (`defXXX`)

- rename buffer() => defBuffer()
- rename fbo() => defFBO()
- rename rbo() => defRBO()
- rename multipass() => defMultiPass()
- rename shader() => defShader()
- rename texture() => defTexture()
- rename cubeMap() => defTextureCubeMap()
- rename floatTexture() => defTextureFloat()
- rename cube() => defCubeModel()
- rename quad() => defQuadModel()
postspectacular added a commit that referenced this issue Apr 15, 2020
BREAKING CHANGE: rename HOF words

- add `def` prefix for all HOF words (#210)
  - word/U => defWord/U
  - tuple => defTuple
  - join => defJoin
  - op1/2/2v => defOp1/2/2v
  - cond => defCond
  - cases => defCases
  - loadkey => defLoadKey
  - storekey => defStoreKey
  - loop => defLoop
  - push => defPush
- add new plain words: catr, join
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant