> It boils down to problem definition. The function is supposed to keep > track of n (updating it) on each call then yes, an object is part of > the only solution. > Only because of the need for a static variable. Pretty hard to come up > a non-object version for handling static variables, but I maintain its > unrelated to closures.
If you check the list of solutions provided at http://www.paulgraham.com/accgen.html you'll see that many are based on the fact that many languages can return closures. Take Scheme, Javascript, Lua, Ruby... The function foo returns a function AND the hidden counter n. The complete set function plus hidden counter is the closure I was referring to. The location called "n" is only visible from inside the function returned from foo, and so it's a part of it that cannot be separated from the whole. In languages like Python or VBScript, instead, one cannot return a function plus a hidden counter, so what they return is an object. But many compilers for Scheme (just to mention an example of FP: there are others and the literature available on the Internet is quite vast) that target OO platforms like Sun's Java or Microsoft's CLR, will transform closures into objects. The same happens in the latest C# compiler (2.0) where generators ("return yield") and anonymous delegates actually capture the live environment of their instance spot by, actually, being translated into objects whose hidden members mirror the required variables from the environment. -- WildHeart'2k6 - mailto:[EMAIL PROTECTED] My digipics and blogs: http://spaces.msn.com/members/wildy2k5/ [[All I Ever Learned, I Learned From Anime: // Snow means love.]] ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
