| Neil Madden 2006-09-29, 4:08 am |
| Bruce Stephens wrote:
[...]
> I'm just thinking that one of the objections against adding closures
> to Java and C++ is that you can get almost the same effect just by
> putting whatever you want saved in an object. But then that forces
> you to list everything you want saved, whereas you don't with
> closures. But if you have to list things with closures, then that
> seems to me to weaken the case for closures quite a bit.
(/me notes that Java already has closures in the form of anonymous inner
classes, they're just uuuugly).
Except that a closure captures its lexical environment, not a newly
created environment. Compare:
proc myProc {params} {a b c} {
...
}
to
object myObj
myObj var a $a
myObj var b $b
myObj var c $c
myObj method myProc {params} { ... }
In the object case, we have to explicitly copy the lexical environment
into the object. Sure, you could sugar the latter to look like the
former (effectively implementing closures as objects), but it seems
simpler to just allow the former.
> Maybe I'm thinking in terms of static languages (where if you create
> an object without any inheritance or anything then it never has
> inheritance, so it has no particular overhead).
Well, you could possibly do this sort of optimisation with something
like ITcl, which has a static inheritance relationship, IIRC (i.e., you
can't change the superclass of a class after definition time). I don't
know if it is done though. But why start from a hammer and try and
optimise away unnecessary weight?
-- Neil
|