James,
Thank you for your explanation. This was very helpful for me to get a better
understanding of some of the confusing nomenclature between Java and Scala, as
did the Moors, Piessens, Odersky paper that's been linked to previously
(http://www.cs.kuleuven.be/~adriaan/files/higher.pdf).
I believe I understand your example, but I'm not sure I see the major gain.
After all, the following is legal Java:
public class Util
{
public static <S, T> void map(Iterable<? extends S> source, Collection<?
super T> target, Transformer<S, T> trans)
{
for(S val : source)
target.add(trans.transform(val));
}
}
Yes, its clients will have to use perhaps 3 lines instead of 1. Is that what
this is really all about, or am I missing something?
Alexey
--- On Sat, 12/27/08, James Iry <[email protected]> wrote:
> From: James Iry <[email protected]>
> Subject: [The Java Posse] Re: Scala for the enterprise?
> To: "The Java Posse" <[email protected]>
> Date: Saturday, December 27, 2008, 12:45 PM
> Tony's um...debating style shouldn't be taken as
> reflecting the Scala
> community in general.
>
> To the topic at hand: Scala has only a few things are are
> genuinely
> foreign to Java programmers. For instance, except for
> non-local
> return, Scala's lambdas are really just a shortcut to
> writing certain
> kinds of anonymous inner classes and closures are just
> instances of
> them (people often use the word closure where they mean
> lambda -
> that's not really correct, but in general that's no
> more confusing
> than saying object where you mean class).
>
> Higher kinded types are one such fairly new thing. But if
> you step
> back they're just a logical extension to stuff Java
> programmers
> already know with regards to generics. And what they
> enable, in a
> nutshell, is better type specification and more code reuse.
>
> In Java, Foo, List<Foo>, and List<? extends
> Foo> are all types. As
> such, they are all suitable for substitution in X in
> "public <X> X
> doSomething(X x) {...}". Here we don't know what
> doSomething does
> exactly, but we do know that given a value of type X it
> returns a
> value of the same type X.
>
> But sometimes it's useful to change a type in certain
> well constrained
> ways. The example from the linked paper was
> "mapping" (not to be
> confused with the Java Map interface). Mapping means
> taking a
> container of type Container<Contained> and using a
> transformer on each
> element to return a container of type
> Container<NewContained>. In
> other words, take an ArrayList<String> and turn it
> into an
> ArrayList<Integer>, or take a Tree<Foo> and
> return a Tree<Bar>. Etc.
> The important part is the form of the container doesn't
> change, while
> the type of contained element changes according to the
> transformer.
>
> In Java you can't express that idea generically
>
> First, start with this interface
> interface Transformer<Arg, Result> {
> public Result transform(Arg arg);
> }
>
> With that, the following is not valid Java and there's
> no way to
> express it
>
> interface Mappable<Container<?>, Contained> {
> public <NewContained> Container<NewContained>
> map
> (Transformer<Contained, NewContained> transformer);
> }
>
> The best you can do in Java is
> interface Mappable<Contained> {
> public <NewContained> Mappable<NewContained>
> map
> (Transformer<Contained, NewContained> transformer);
> }
>
> Which just says that if, say, MySimpleContainer implemented
> Mappable
> then using its map method would return some arbitrary
> Mappable rather
> than another MySimpleContainer.
>
> In Scala, on the other hand, this is valid
> trait Mappable[Container[_], Contained] {
> def map[NewContained] (transformer :
> Transformer[Contained,
> NewContained]) : Container[NewContained]
> }
>
> class MySimpleContainer[T](x : T) extends
> Mappable[MySimpleContainer,
> T] {
> def map[NewContained](transformer :
> Transformer[Contained,
> NewContained) =
> new MySimpleContainer(transformer.transform(x))
> }
>
> So this says that MySimpleContainer's map returns
> another
> MySimpleContainer. Exactly what we want. Note that I
> don't need the
> Tranformer interface at all since that's just the same
> thing as a
> closure, but I wanted to keep the examples symmetrical.
> Also, while
> MySimpleContainer is a bit silly, the idea extends to
> lists, trees,
> dictionaries (maps), etc.
>
> At this point, all it seems that I've accomplished is a
> tighter type
> specification. Which is fine, but is it really that
> useful? Well, if
> you go on a bit further then if you have both a higher
> kinded
> Buildable interface and a higher kinded form of iteration,
> then you
> can write map once and reuse it.
>
> Long story short: higher kinded types allow you to more
> precisely
> specify what an interface means while also allowing greater
> reuse.
>
> On Dec 26, 10:52 am, Alexey Zinger
> <[email protected]> wrote:
> > This thread, while interesting at times, is getting
> difficult to follow, mainly due to it getting sidetracked
> like this. A simple observation: being smart is attractive
> (not just in a sexual way), while being smart and making
> sure everyone knows it is not nearly so. I'm not a
> computer scientist and most of my programming-related time
> is spent strongly swayed by pragmatic considerations. That
> said, I get the value of a good grasp on language theory, as
> it can open one's mind to new ideas and possibilities.
> So I'd love to hear more about Scala from that
> perspective, but I'd love to hear much much less about
> who thought of higher kinded types first and who got kicked
> out of an IRC channel when. Thanks, gents. Carry on.
> >
> > Alexey
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
