I'll reply here now, but if anyone suggests taking it off-list after
this message that's fine by me.
On Wed, Nov 23, 2011 at 8:05 PM, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> For example:
> someBitSet map {_.toString}
> is only able to return a Set[String] thanks to an mechanism based on
> implicits
That's implicit parameters as far as I know, whereas I was talking
about removing implicit conversions.
> I used a self-type only today! They just make some things so much easier...
> Especially when coupled with structural typing, self types really do make
> some problems a great deal more approachable.
They seem to be used for avoiding making a type generic.
> Existential types. Wildcards were a mistake in Java, they don't
> really need to be copied over. There are reasons for not having 100%
> compatibility, and sanity is one of them.
> They're also, sadly, a necessary evil for dealing with certain Java
> libraries. If Scala were to remove features that enable interop, then
> existential types most definitely would not be the first on my list!
One could write a bit of Java code that exposes a wildcard-less
version of a class to Scala. Not the ideal perhaps, but in the
interests of simplicity it might be for the best.
> As it
> is, interop was a core design choice of Scala, so existentials really can't
> be removed.
The interop is great from Java to Scala but terrible the other way
around. object X { val x = 5 } generates a class file named X$, for
instance. There are reasons but they are based on engineering choices
that could reasonably have gone the other way.
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
