stack-bound vs. travelling closures proposal.

[Jesse Kuhnert]

It seems to me that even though some of the syntax being paraded
around could be better, it is a wholly separate problem than the core
goal of this project.

The ease with which you can modify things in mercurial to come to your
desired results might speak more to the careful thought and purity
maintained in the language rather than how easy the temporary solution
may seem. I only say this because I've fallen in to the same trap
before only to curse my newbie ways later on when I realized what I
had done. I had some kind mentors and good code to read from people
like Howard Lewis-Ship, but I don't think the language is any place to
allow people to make their own mistakes.

More or less I think people agree with you that some form of inference
would be nice, but it needs to be done broadly and elegantly or else
things will start to fall apart. Much like the quarantined sections of
my current codebase written in scala. Nice in theory but just give me
closures and I can do away with all of it.

Also don't agree with all the naysaying with generics. Yes of course I
had more than a few puzzling moments adding support for them to my
ognl jit extension and whatnot but overall it has been a tremendous
blessing. Countless lines of code saved for anyone that hates
repeating themselves - thank you for that.

Let's continue to attack each problem wholly and one at a time and fit
closures in to the language the only current elegant ways that we can.

On Thursday, June 17, 2010, Reinier Zwitserloot <reinier at zwitserloot.com> wrote:
> Parellizing sort can be done in a similar way to the example implementation
> of forEachParallelized.
>
> Yes, it's ugly, and involves both unshackle and sneakyThrow, but it would
> work just fine. The alternative is something like this:
>
>     public <T, throws E> void parallelSorter(List<T> list, #int(T, T)(throws
> E) comparator) throws E {
>         ....
>     }
>
> But this is littered with problems as well. For starters,
> java.util.Comparator must be retired. That's a major smell of the strawman
> "throws E" syntactic method. There's no need to retire Comparator in the
> stack-bound proposal. Secondly, the authors of ParallelSorter need to
> understand exactly how to work with "throws E" which is difficult [*1], and
> involves loads of boilerplate. The characters "throws E" occur three times
> in the above snippet!
>
> I'm basically trying to argue that the above really doesn't win over
> unshackle/sneakyThrow in the "that looks pretty" department, stack-bound in
> general is easier to understand (to date the majority of java programmers
> still fundamentally cannot fathom why Enum's signature includes <E extends
> Enum<E>>!) and the disadvantages of the strawman[*2] are as bad or worse
> than the disadvantages of stack-bound[*3].
>
> [*1] It's certainly nothing insurmountable, and plenty of folks are using
> complicated generics today, but it remains a truism that the majority of
> java programmers avoid declarative generics like the plague, and simply
> don't understand them. They love their List<String> and Future<Foo>, but
> don't really know why Enum's signature is officially Enum<E extends
> Enum<E>>, nor why sort's signature is <T> void sort(List<T>, Comparator<?
> super T>) - and not for example void sort(List<? extends T>, Comparator<T>).
>
> [*2] strawman problem: The vast majority of SAM types need to be retired
> because they can't be retrofitted with "throws E", and their replacements
> contain lots of boilerplate.
>
> [*3] stack-bound problem: See the "Future" snippet at the end of the OP
> which simply cannot be done given the stack-bound proposal, but is
> par-for-the-course in strawman.
>
>
>
> --Reinier Zwitserloot
>
>
>
> On Thu, Jun 17, 2010 at 11:20 AM, Neal Gafter <neal at gafter.com> wrote:
>
>> On Wed, Jun 16, 2010 at 11:52 PM, Reinier Zwitserloot
>> <reinier at zwitserloot.com> wrote:
>> > The alternative is working with abstracted exception types, but that
>> cannot
>> > possibly work either. How would you even do that? "catch (T foo)" does
>> not
>> > seem to be possible given the concept of erasure. The only pragmatic
>> thing
>> > one might catch, then, is Throwable or Exception, which one can also do
>> with
>> > the restricted/portable proposal.
>>
>> Right.  The main thing one wants to do with exception transparency is
>> not to catch the exception in the generic code, but to express in the
>> type system that those exceptions are propogated out to the caller.
>> It can be caught at a place where the type parameter takes on a
>> concrete type.  That place might or might not be higher on the call
>> stack of the same thread.
>>
>> Consider the sort() method you described.  How does one use
>> concurrency in the implementation without undermining exception
>> safety?  Passing the comparator to another thread requires storing it
>> in a variable, and that variable has to have a type.
>>
>
>