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

Stop using class for ‘singletons’ #87

Closed
yuchi opened this issue Apr 14, 2015 · 5 comments
Closed

Stop using class for ‘singletons’ #87

yuchi opened this issue Apr 14, 2015 · 5 comments

Comments

@yuchi
Copy link
Contributor

yuchi commented Apr 14, 2015

Using

class dom {
  static addClasses() { /*…*/ }
}

instead of

const dom = {
  addClasses() { /*…*/ }
};

does not bring all that value…

@eduardolundgren
Copy link
Contributor

+1

@yuchi
Copy link
Contributor Author

yuchi commented Apr 14, 2015

Even better?

export function addClasses() { /*…*/ }

@yuchi
Copy link
Contributor Author

yuchi commented Apr 16, 2015

Arguments against named exports:

  1. no support for decorators;
  2. almost impossible to overwrite a method later.

Arguments for named exports:

  1. support for export * from 'dom' in a 'dom-extensions' package;
  2. almost impossible to overwrite a method later.

@mairatma
Copy link
Contributor

mairatma commented Jul 5, 2016

I'll close this since it's very old. For now we're still using class for singletons, mainly because we want to allow overwriting methods, having the library be flexible. We can think about changing this later.

If you think we should still discuss this for now, feel free to reopen this on metal/metal though.

@mairatma mairatma closed this as completed Jul 5, 2016
@yuchi
Copy link
Contributor Author

yuchi commented Jul 5, 2016

but this makes the code fragile and this bound.

jbalsas added a commit that referenced this issue Jan 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants