Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #20957
| From | Steven Simpson <ss@domain.invalid> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? |
| Date | 2013-01-04 23:45 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <i66kr9-5pt.ln1@s.simpson148.btinternet.com> (permalink) |
| References | (5 earlier) <odmer9-onl.ln1@s.simpson148.btinternet.com> <0680c1e0-16cb-4791-8a5f-95a3ff2bcba8@googlegroups.com> <fa166a9f-b0ed-4eba-9789-97ef2f67923a@googlegroups.com> <mcujr9-dfs.ln1@s.simpson148.btinternet.com> <9t7503ltp93d.t74qawj4roq7.dlg@40tude.net> |
On 04/01/13 22:38, Peter Duniho wrote:
> I can't speak for the previous poster. But clearly, closures don't do
> anything you _can't_ do using lambdas or even using some other technique.
>
> The point is convenience, expressiveness, readability, and other code
> authoring and maintenance such as may be of concern are affected. In the
> view of closure proponents (such as my own), these concerns are addressed
> in a positive way when closures are available.
Indeed. I'm interested in seeing how much expressiveness (etc) is lost
when one is forced to work around the lack of a feature, by looking at
specific cases.
> But that's the point: lambdas, closures, etc. offer a more concise,
> expressive way of representing certain algorithm approaches. In this
> context, I can confirm that there are plenty of examples of situations
> where a true closure offers a more convenient, improved way of achieving
> the same desired result, as compared to language syntax without closures.
Do these examples fall into just a couple of categories, in terms of the
guarantees that the user of a function object makes to the provider
about how it will be invoked?:
1. The object will be invoked on the same thread that provided it (e.g.
in an event-driven environment)
2. (1) + the object will not be invoked once the call that provided it
has completed (e.g. in control abstraction)
...or are there more, especially ones which make fewer or alternative
guarantees?
I'm genuinely interested to see if there are more categories. Then, if
they are limited, could a set of type qualifiers express these
guarantees formally, and allow compilers to progressively switch on
features like mutable local capture and various transparencies safely?
--
ss at comp dot lancs dot ac dot uk
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? jeti789@web.de - 2013-01-02 07:08 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? jeti789@web.de - 2013-01-02 07:52 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-02 17:33 +0000
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-02 11:31 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Lew <lewbloch@gmail.com> - 2013-01-02 12:52 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-02 20:58 -0400
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Lew <lewbloch@gmail.com> - 2013-01-02 17:40 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-03 20:43 -0400
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-02 23:44 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Patricia Shanahan <pats@acm.org> - 2013-01-03 07:57 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Lew <lewbloch@gmail.com> - 2013-01-03 13:22 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Patricia Shanahan <pats@acm.org> - 2013-01-03 16:14 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-02 21:46 +0000
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Lew <lewbloch@gmail.com> - 2013-01-02 17:35 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-03 02:13 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-03 06:45 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-04 21:32 +0000
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-04 14:38 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-04 23:45 +0000
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-04 17:24 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-05 13:20 +0000
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-05 01:50 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-05 11:21 +0000
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-05 04:27 -0800
Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-05 12:58 +0000
csiph-web