> FTR, we considered and rejected use-site extension methods in 8, for a > philosophical reason that is still equally valid here: an API developers > should own their API. What we rejected is the use-site aspect of it; > the part we actually liked (but didn't have enough motivation to embrace > in 8) was the partiality. Just as default methods support the > after-the-fact aspect of API extension that use-site extension would > (without the transparency risks), partial methods (including partial > defaults) support the specialized-receiver aspect of extension methods > that we like but don't yet have. > > >
Well, I’m not suggesting we add extension methods, only if fluent APIs are that important, and even then we don’t really need extension methods if we (rightly) want people to own their API, just a threading operator, a-la Clojure: stream => sum() (compiled to sum(stream)) BTW, for sum specifically to be fluent it requires neither approach. I think that stream.reduce(sum()) is just as good as stream.sum() In fact, I prefer it, because it feels very general. But anyway, if partiality is something we want for its own sake, then partial methods FTW! :)
