Re^3: How A Technique Becomes Over-rated

I didnt, and apologies if i came across as an OOP-advocate on the defense. My point was that eventually, you get the computer to execute some machine instructions - everything else is organization. Higher-Order functions just dont seem that organized.

In your re-write, you would have to create a new kind of compare package/function combo for every single type of comparison you wanted before you could use it.

Of course, but the functional approach still requires creating the function. In Perl, if you are using closures to do this, then they too are static comparisons created before you use them. If your using eval, then all bets are off...
The package is a limit in Perl's implementation. In Java you might approach this by defining the subclasses algorithm during its instanciation, eg:

    // not as useful as closures, not even 'close'...
    Max max = new Max(){ boolean compare(Object a,Object b){ ... } };
    while(...){
        ....
    }
[download]

or more likely, just assume types need to be compared in general

   class Whatever implements Comparable
   {
       // used by generic sort (or max) routines
       public int compareTo(Object o){....}
   }
[download]

All of these do a similar thing - accomodate abstracting the 'flavour' of an algorithm while allowing the programmer to customize the relevent parts. The Object Oriented ones do so in an explicit, structured way, requiring very little additional documentation or conceptual leaps.

Really, Im no OOP advocate. But I am inclined to accept the 50 years of engineering experience that has passed since LISP was invented.

time was, I could move my arms like a bird and...

Comment on Re^3: How A Technique Becomes Over-rated Select or Download Code

Replies are listed 'Best First'.
Re^4: How A Technique Becomes Over-rated by QM (Parson) on Sep 22, 2005 at 19:17 UTC
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 {...} ...` [download] 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	[reply] [d/l] [select]
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...	[reply]
Re^6: How A Technique Becomes Over-rated by QM (Parson) on Sep 23, 2005 at 14:48 UTC
...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	[reply] [d/l] [select]
Re^7: How A Technique Becomes Over-rated by Ctrl-z (Friar) on Sep 23, 2005 at 17:56 UTC
Re^8: How A Technique Becomes Over-rated by Anonymous Monk on Sep 23, 2005 at 18:14 UTC
Re^6: How A Technique Becomes Over-rated by Anonymous Monk on Sep 23, 2005 at 14:59 UTC
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;` [download]	[reply] [d/l]


P is for Practical
	PerlMonks