I think this is a difficult discussion to have online. I'm not advocating exposing "internals" at all. I think we disagree on the line between internal and external. But I don't wanna hijack this thread, so I'll take it back to the other one and respond a bit later.
:Marco On Wed, Feb 8, 2012 at 7:22 PM, Ben Noordhuis <i...@bnoordhuis.nl> wrote: > On Thu, Feb 9, 2012 at 03:58, Marco Rogers <marco.rog...@gmail.com> wrote: > > I also think there is a bit of a contradiction between "low level" and > > "hiding implementation". IMO low level apis should expose as much as of > the > > guts as possible (in a clean and consistent way) to provide maximum > > flexibility for higher level abstractions. If you feel like "Exposing > > ctors really invites the wrong kind of composability", then we should > offer > > a more constructive way to achieve those goals. If we find can't, perhaps > > that means the api is hiding too much. This is what we're dealing with > now > > with http. That other thread points to the fact that child_process has > the > > same problem. > > The problem with exposing internals is that they can never, ever > change if they're part of a stable API. Exposing internals is > therefore only viable if the Node API got split into stable and > unstable parts, where the high level API is stable and the low level > API is not (and let the kibitzing on what constitutes high level and > low level begin). But how useful is an API that changes at whim? > -- Marco Rogers marco.rog...@gmail.com | https://twitter.com/polotek Life is ten percent what happens to you and ninety percent how you respond to it. - Lou Holtz
