I wanted to say that I consider the existing "named" closures to be
useful and cool, too, if only because they let you create something
with object-like behavior, a good deal more succinctly than creating a
Coincidentally, about a week ago, I submitted an example of Beanshell
code to the "99
Bottles of Beer"* web site, and it uses closures in this way. The site
* The idea behind this site is to take a simple programming task --
write a program that prints out the lyrics to the "99 Bottles of
Beer" song -- and collect implementations of it in as many
programming languages as possible. It's still growing: last week,
just after my contribution, they were at 713 languages, and now
they're at 721. Warning: if you're a language geek like I am, it
can be a great time sink.
From: Pat Niemeyer <pat@pa...>
Re: Using method closures...
> I know Beanshell trivially supports method closures (things that
> a "this" reference). Closures are supposed to be "cool" (i.e.,
> Does anyone have any examples of situations where they are useful?
I think that the "cool" stuff generally centers around what I guess
call anonymous closures... and utilities that accept those as part of
What that means is the ability to basically pass a chunk of code as an
argument to a method and have the method evaluate it when it needs it,
with various kinds of control over binding variables to it...
BeanShell doesn"t currently have a syntax for making these kinds of
closures... only named ones (the return "this" kind) that are bound
the namespace in which they were created). There is nothing
difficult about doing this and in fact BeanShell has all the tools to
it... you could sort of roll your own using the setNameSpace() or
namespace setParent() methods and the this.caller reference. But
not friendly of course.