#3867·faker

Design Consideration: Standalone Module Function this parameter

Author: ST-DDTCreated May 30, 2026Updated Aug 15, 2026
Labelsquestionp: 1-normals: needs decisionc: refactor

This is more of a design consideration for discussion than an actual proposal. (ADR?)

Instead of explicitly passing fakerCore to each SMF, we could use a this: FakerCore parameter.

typescript
// Explicit Parameter
function firstName(fakerCore: FakerCore) {
  return arrayElement(fakerCore, fakerCore.locale.person.first_name);
}

// Direct Use A
fristName(enCore)

// Direct Use B
const enFirstName = bindTo(firstName, enCore);

enFirstName();

// Indirect Use A
function mockUser() {
  return { firstName: firstName(enCore) };
}

mockUser();

// Indirect Use B
function mockUser(fakerCore = enCore) {
  return { firstName: firstName(fakerCore) };
}

mockUser();
typescript
// This Parameter
function firstName(this: FakerCore) {
  return arrayElement(this.locale.person.first_name);
}

// Direct Use
const enFirstName = firstName.bindTo(enCore);

enFirstName();

// Indirect Use
function mockUser() {
  return { firstName: firstName() };
}

const enMockUser = mockUser.bindTo(enCore);

enMockUser();

Pros:

  • One less parameter to pass
  • No need to import localized core during use
  • Unverified: No javadoc information loss on bind in comparison to custom bind implementations

Cons:

  • Usage of a SMFs requires calling bindTo
  • Most uses get encapsulated in a function call anyway, so there difference in usage is hardly noticible anyway
  • Miniscule RAM overhead.
  • Harder to deal with multiple cores/languages in one fn.
  • Harder to detect whether this has been bound correctly.
  • Possible this collision if weaving faker and external methods

I think we talked about it before, but I couldnt find any issues/docs/comments that contain any this vs parameter discussion.

Did I miss anything? Which do you prefer?