Come for the quick hacks, stay for the epiphanies. | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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")In reply to (tye)Re3: Why Closures?
by tye
|
|