in reply to Re (tilly) 2: Why Closures?
in thread Why Closures?
I think your point is that a system of closures is probably more powerful than a system of objects. I don't disagree with that [ I won't go quite so far as to agree, but I do suspect that you might be right (: ]. I think that frankus' point was that a single closure is very much like a single, very simple object. I will go so far as to completely agree with that.
A closure is very much like an object with a single method. This can be a great advantage if you want "an object with a single method" because a closure doesn't require you to create all of that OO baggage (most notably a class name that must fit into a global namespace).
Since I'm standing up here and some of you are looking at me, here is my breakdown of the major programming methodologies supported by Perl:
Procedural programming has data and subroutines and you associate them together "by hand". Object-oriented programming has data where each type of data is tightly associated with a collection of subroutines. Functional programming treats subroutines as data and allows you to associate items of data with each subroutine.
Now, if you do a whole project using one methodology, then more differences crop up. But I like to mix methodologies in Perl so those are the main difference for me.
So if I want a collection of subroutines that work on similar data, I'll create a class (and make it a module).
If I have a single subroutine that works on different instances of similar data, then I have to decide whether I'm likely to want to add more subroutines later. If so, I'll make a class. If not, I'll make closures.
If I have a chunk of behavior that I want to allow people to change, then I'll probably use a code reference. If that behavior should be associated to different instance of similar data, then I'll use a closures.
- tye (but my friends call me "Tye")
|
|---|