On Feb 8, 2012, at February 8, 20129:58 PM, Marco Rogers 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.
I think the "wrong kind of composability" Isaac is describing is a world in which everyone writes their own ServerRequest and ServerResponse that extend the base prototype, or worse that actually mutate the base prototypes (which is a danger). We can enable the same kind of extension by making those objects composable and this is actually a more useful form of extension because people deal with these objects as the subject of events. While I have everyone's attention though, I do think that exposing ctors for objects we only return instances of via create methods (sub processes, fs streams, client sockets) actually should be exposed so that they can be used by developers to create new objects that are extended. If we are concerned about people mutating the global prototypes then the language gives us a facility to prevent this, we can freeze them. There would be a performance penalty, so the question becomes: do we care more about performance than extensibility? To many people this is a question between speed and usefulness.
