@wycats But is it a reasonable assumption that *all* modules are like that?
-
-
-
@jankrems it's reasonable to encourage it imho. -
@wycats "Encourage" assumes that single export is the better choice in all or almost all cases. -
@jankrems either single or a small number of named, yes. Almost never gargantuan modules like fs. -
@wycats What about "talking" modules like assert.equal, async.map? Seems like stepping back into pre-namespace C land. -
@jankrems what's a talking module? -
@wycats A module name that is part of the "sentence". "Assert [that it's] equal" -> `assert.equal`. -
@wycats I'm not saying that single export is bad and/or shouldn't be the default case. Just that "namespaced import" has real use cases. - 2 more replies
New conversation -
-
-
@wycats so what about stuff like lodash or ember style libraries? Repositioning default as a pseudo module has some big downside -
@stefanpenner as long as you only need a few exports at a time you're good. Ember should have "ember/object" etc. -
@wycats are you proposing we use both default as module and granular property exports? -
@stefanpenner import { get, set } from "ember/accessors"; import View from "ember/view" -
@wycats ah ok. I thought you where advocating put everything on default. I was about to be concerned
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.