-
Website
http://drawohara.com/ -
Original page
http://drawohara.com/post/39090749 -
Subscribe
All Comments -
Community
-
Top Commenters
-
adityagholap
1 comment · 1 points
-
avdi
2 comments · 4 points
-
somethingsomething
1 comment · 1 points
-
Michael Guterl
14 comments · 1 points
-
bbebop
1 comment · 3 points
-
-
Popular Threads
-
drawohara - Ski tu-tu. You?
2 weeks ago · 2 comments
-
drawohara - Lancelot.
1 week ago · 1 comment
-
drawohara - Ski tu-tu. You?
yeah there are a few reasons
1) if i used functions i'd have to pass info to each of them. when i'm working up a short script it's sometime easier to make functions work 'over' data (closure style) since it allows me to play around with what the lambda's do without concern for data passing or signature design. note how the lambdas affect the var 'n' as an example.
2) def is ugly for short scripts.
as a script like this matured i'd steer towards a class based approach since it allows the same functionality in a more 'normal' rubylike way of doing things: namely encapsulating the data functions work over as instance vars. nevertheless if you imagine that script being wrapped in 'class Wrapper...' and the data the lambdas work on as @ivars you'll see that using closures in this way effectively makes the script an 'instance' of an object whose class is defined by the script itself.
for example:
* encapsulation via objects
class Example
def initialize
@x = 40
end
def inc!
@x += 2
end
end
example = Example.new
example.inc!
* encapsulation via closures
#! /bin/bash
x = 40
inc = lambda{ x += 2 }
inc.call