Hacker News new | ask | show | jobs
by soc88 5100 days ago
> I may also be missing the point but what prevents you from putting a count method on an enumerable with a default implementation which does the same?

Isn't that exactly what we're talking about?

The huge difference between C#'s extension methods and traits is that the first one is statically dispatched, the second one dynamically.

This means classes with a better implementation can just override Count() and suffer none of the problems of the extension method approach.

Scala also offers implicits to "enrich" existing types, slightly comparable to Extension methods, but a lot more general.

Whereas extension methods only support some ad-hoc "addition" of members to existing types, Scala's implicits allow you to use these methods to implement new interfaces -- and isn't that the reason why you add methods in the first place: to implement interfaces?

> So for a (poor) example you might extend float so you could convert an angle to a 2d unit vector, but only in given bits of your program you want to be converting between angles and vectors.

   implicit def floatTo2DUnitVector(angle: Float) = 2DUnitVector(...)
Done. Import where you need it.

Btw, C# has some limited form of implicits, too, but I haven't seen any serious usage of them for a while.

1 comments

> This means classes with a better implementation can just override Count() and suffer none of the problems of the extension method approach.

Instance methods are bound before extension methods, if someone provides an implementation of Count() in a subclass it'll be invoked instead (provided your reference is typed appropriately). More narrow extension methods are bound before general ones, so you can even "override" within extension methods.

Scala has some neat stuff, but it's not Java 8 so I don't see how it's relevant.

> Btw, C# has some limited form of implicits, too, but I haven't seen any serious usage of them for a while.

C# has implicit conversion operators you can define, http://msdn.microsoft.com/en-us/library/z5z9kes2(v=vs.100).a... . You'd better have a really good reason for defining one though, silent conversions are generally frowned upon.

That's exactly the issue I'm talking about: you can't “enforce” the static type, so different methods get called depending on whether you pass List foo = MyList(...) or MyList foo = MyList(...), which is acceptable for static methods, but a source of bugs when they can be made to look like instance methods.

> Scala has some neat stuff, but it's not Java 8 so I don't see how it's relevant.

Java's default methods are basically Scala's traits (just made a bit more cumbersome to make Java developers feel right at home), so what I said about traits applies to “interfaces with default methods”, too.