If you go the source dependencies way, you cannot add a public method to any of your types, ever. Because that breaks backward source compatibility. Yes, binary compatibility is hard. But source compatibility is *impossible*.
-
This Tweet is unavailable.
-
-
Replying to @sjrdoeraene @fommil
But source compatibility is *safe* (the compiler checks it), whereas binary compatibility is *risky*. Composing a classpath at the same time as compilation guarantees there's no mismatch between the two... at the not-insignificant cost of having to compile the world.
2 replies 0 retweets 3 likes -
This Tweet is unavailable.
-
I don't understand how you can "fix it right there and then" for source compat any more than for binary compat. In both cases, you'll have to fiddle with your dependency's source code, which means forking it in either case.
1 reply 0 retweets 1 like -
Replying to @sjrdoeraene @fommil
I think the point is that Fury makes that easy. It will be a single command to move a source dependency out of Fury's private control and into your workspace to edit. Then you can fork and create a PR quite easily.
2 replies 0 retweets 4 likes -
making that easy is orthogonal though. also let's not forget not all jvm classpath users will be re-compiling with scalac from source: this path might lead to the scala ecosystem becoming hostile to the java ecosystem..
0 replies 0 retweets 1 like -
This Tweet is unavailable.
-
That should only be Fury users, though. The existing infrastructure around binary distribution should continue to function, I hope...
1 reply 0 retweets 0 likes -
if they still put in the effort to care about binary compatibility..
1 reply 0 retweets 1 like
Yeah... is "disruption" considered good or bad these days?
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.