Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^4: How A Technique Becomes Over-rated

by QM (Vicar)
on Sep 22, 2005 at 19:17 UTC ( #494258=note: print w/ replies, xml ) Need Help??


in reply to Re^3: How A Technique Becomes Over-rated
in thread How A Function Becomes Higher Order

Sticking my nose in where it doesn't belong...

If I understand it right, one of the points of L~R's original post was that the comparison function can be defined by the user, and passed in as a coderef. If I understand your post, you seem to be saying that the same end result can be achieved through OO and classes.

But I'm fuzzy on what you suggest should happen in OO. If the class has a compare method that doesn't work for my current problem, do I subclass it and create my own maxstr? Do I append to the class my own method?

... package SomeClass; sub my_compare {...} ...
What if each object needs a unique compare function? What if these functions aren't known at compile time? What if there are so many functions that it's difficult to give them all unique and useful names?

I'm not sure that any of these questions are easier or harder to answer in OO vs. closures.

-QM
--
Quantum Mechanics: The dreams stuff is made of


Comment on Re^4: How A Technique Becomes Over-rated
Select or Download Code
Re^5: How A Technique Becomes Over-rated
by Ctrl-z (Friar) on Sep 23, 2005 at 11:58 UTC
    If the class has a compare method that doesn't work for my current problem, do I subclass it and create my own maxstr?

    If you are referring to my original post, then yes. The Max class abstracts the algorithm of calculating a maximum of objects - the subclass implements the comparison in the appropriate context. Im not suggesting this is the best OO solution, just one that is like the Higher-Order equivalent.

    If you meant "Foo.compareTo() doesnt compare Foos like I want", then the solution depends on (among other things) how much internal access you need to compute the comparison. There are quite a few ways this could be approached but to bring it back to my original point, they are mostly structured and organized - not hidden un-garbage-collected variables and blind function dereferencing.

    What if each object needs a unique compare function?
    Then what are you comparing it to? I would have thought similarity was a prerequisite for comparison.
    What if these functions aren't known at compile time?
    Closures are compiled too. That is, whether you use gt or > (or whatever) is decided at compile time - there is no runtime dynamic there.
    What if there are so many functions that it's difficult to give them all unique and useful names?

    They are all called 'compare' - different classes do different things when it is invoked.

    update: clarification - Im not sure Im addressing your questions?




    time was, I could move my arms like a bird and...
      ...they are mostly structured and organized - not 50 line anonymous subroutines defined in the middle of another subroutine, with access to the parent's local variables even after it has returned.
      I don't think that's a fair characterization (the sub shown is only 5 lines, and 2 of those are comments), and certainly isn't the point.

      The parents "local" variables are lexical, and they are created explicitly for the closure. If I bake you a turnover, serve it on a paper plate, and give you a plastic fork to eat it with, should I be annoyed that you still have the plate and fork, or worse, have recycled them when you finished?

      What if each object needs a unique compare function?
      Then what are you comparing it to? I would have thought similarity was a prerequisite for comparison.
      Sorry, that should say each pair of objects. More descriptively, what if each object is a collection, and needs a unique next method? But there are so many of unique collections that you can't precode classes for all of them? Which suggests similarities to Streams, which comes back to HOP.

      What if these functions aren't known at compile time?
      Closures are compiled too. That is, whether you use gt or > (or whatever) is decided at compile time. Its just the variables that change.
      Ah, you see the gap approaching? Whether to use gt or > can be decided at compile time, but doesn't need to be. The leap of insight is that some higher caller can pass in a coderef to use in place of any predefined notions of how a comparison function should work. If the closure is coded well -- no unnecessary assumptions, just the fundamental "give me a coderef that I can pretend is a comparison function" -- and then the closure is more general and more useful than was ever imagined.

      For an example, see the opening chapters of HOP, where the <code>dir_walk<code> directory walker function is gradually transmogrified into a generic traversal function, then used as a web spider.

      In the end, it's the tool you know that gets used. It took me 3 days to put together one of those Walmart entertainment centers. Then I discovered electric screwdrivers, and never looked back.

      -QM
      --
      Quantum Mechanics: The dreams stuff is made of

        I don't think that's a fair characterization

        You are right (though it might be the point), I had changed it while you were responding. Regarding your analogy, you might be annoyed that I leave with your plate and fork and carry it wherever I go, even after you move out - and noone believes you as the plate and fork are now invisible to everyone ;-)

        I appreciate what you are saying, and to quote from HOP

        ...I think the functional style leads to a lighter-weight solution...that keeps the parameter functions close to the places they are used instead of stuck off in a class file. But the important point is that although the styles are different, the decomposition of the original function into useful components has exactly the same structure.

        The point about closesness is a good one. Its not possible in OO Perl and only kind of possible in Java, as I tried to show in an earlier post. But, by limiting your customization technique to callbacks, all shared state must be stored in the lexical scope of the caller. By limiting your object to a coderef, theres only one thing you can do with it - call it. Thats fine for simpler stuff - number generators, map, grep etc - and I like those kind of ideas. But its definitely not the tool I know for building relatively complicated software.




        time was, I could move my arms like a bird and...
      Closures are compiled too. That is, whether you use gt or > (or whatever) is decided at compile time - there is no runtime dynamic there.
      @list = qw/123 3.14 foo bar 42/; $q = <>; chomp $q; $test = ($q eq "num") ? sub{ $a <=> $b } : sub{ $a cmp $b }; $\="\n"; print join ",", sort $test @list;

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://494258]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (9)
As of 2014-09-03 05:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (35 votes), past polls