@brianleroux so there is no one person at fault.
-
-
Replying to @wycats
@brianleroux the only possible solution is to disallow ALL modules from returning instances of classes defined in another module.1 reply 0 retweets 0 likes -
Replying to @wycats
@brianleroux people think this is tenable, but it isn't.1 reply 0 retweets 0 likes -
Replying to @wycats
@brianleroux (return includes calling a callback from another module with an instance of a class from yet another module)2 replies 0 retweets 0 likes -
Replying to @wycats
@wycats@brianleroux I think I get you. You skirt some of this if common classes are built-in/standardized. e.g. python datetime?1 reply 0 retweets 0 likes -
-
Replying to @wycats
@polotek@brianleroux but that restriction means shared types bottleneck on standardization (the opposite of the point of npm)2 replies 0 retweets 0 likes -
Replying to @wycats
@wycats@brianleroux it feels like this might be a bad idea w/ custom types. You'd be coupling modules together. Or maybe that's your point.1 reply 0 retweets 0 likes -
Replying to @polotek
@polotek@brianleroux it's common with things like http libs (shared request types) but people go into contortions to explain "bad idea"2 replies 0 retweets 0 likes -
Replying to @wycats
@wycats@brianleroux I believe it should be possible and viable for common shared types. But proliferation would probably be bad.1 reply 0 retweets 0 likes
@polotek @brianleroux you just need a way to say "this package defines a shared type so there can be only one" (highlander rule)
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.