Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

[Perl 6] Method call versus function call on a data set

by w-ber (Hermit)
on May 29, 2007 at 22:47 UTC ( #618075=perlmeditation: print w/ replies, xml ) Need Help??

(This is not really Perl 6 specific, but it was Perl 6 syntax that made me think about the matter.)

In Perl 6, arrays are now objects, namely inheriting from Array, as in any self-respecting object-oriented language. As a trivial case example, suppose you want to grep for something in an arbitrary array. In Perl 5 style, you can do it as a function call to grep, giving the array as a parameter:

# Function call style. if (grep $something, @array) { ... } my @result = grep $thingie, @array;

In Perl 6, one of the many ways to do this is to use the method call syntax on the array itself:

# Method call style. if @array.grep($something) { ... } my @result = @array.grep($thingie);

In the former, it is clear, at least to a Perl 5 programmer, that one has to have an array or at least something acting exactly like an array (implementing the same interface) as an argument to grep, since this is really what we are doing: grepping an array.

In the latter, the array acts as an object that happens to have the method grep, which, as it happens, will grep the array for us.

I'm not against object-oriented programming, which certainly has its place. I'm not against abstract data structures, which are certainly very useful. However, I find the latter, method call style mentally more taxing than the former, function call style. This is because in the general case, or even in this particular case, in order to find out what methods the data structure supports, one has to find out the exact type of the data structure. Perhaps it's an Array, but is it also a Frobnicator, and does it implement the role JackInTheBox? What will grep do with this data structure (or object), anyway? To find out for sure, one has to know where grep has been defined or overloaded.

This sounds silly, but it is what my unconscious has been giving me warnings about. Consider any "standard methods" for standard datatypes, such as push, pop, and grep for Array. What if the datatype we are using overloads any of those, but we want to be sure we always use the standard grep? Perhaps this is a non-issue, as one can always use the function call syntax to force interpreting grepping as grepping on an Array, or in some other way force the variable to be interpreted as an Array.

However, the other issue stands: For some reason, I find it much harder to (imagine) finding out which methods a datatype has instead of looking up built-in function definitions from perlfunc, and then weeding out those that won't work for this particular datatype I'm using (Array, Hash, etc.). This is because there can be potentially an infinite number of datatypes, all with their own set of methods. True, there can also be a potentially infinite list of (built-in) functions that operate on certain kinds of data, but at least it is always clear from the function signature what it expects the data to be and from the description what it does.

Maybe I just need to write more OOP code and leave the procedural and functional worlds for a while.

(As a sidenote, there are many other ways in which to grep in Perl 6, such as:
# Feed style. my @result <== grep $thingie <== @array; @array ==> grep $thingie ==> my @result; # Another method call style. my @result = grep @array: $thingie;
The feed style doesn't suffer from this problem, but the alternative method call style does.)

--
print "Just Another Perl Adept\n";

Comment on [Perl 6] Method call versus function call on a data set
Select or Download Code
Re: [Perl 6] Method call versus function call on a data set
by moritz (Cardinal) on May 29, 2007 at 23:11 UTC
    While in theory I can understand your worries about having to memoize which class implement which method, it's not such a big deal in real life.

    When you use grep on something similar to an array, it will just automagically work.

    And it works because everything that is similar to an array does (implements) the Sequence Role (in Perl 6 that is), but from the user's point of view you don't need to know that.

    So if your libraries are designed carefully, you don't need to think very much at all - if the methods you try to use make sense in that context, they are most probably implemented. And if not, the compiler/interpreter will complain - not nice, but it doesn't really happen very often.

Re: [Perl 6] Method call versus function call on a data set
by hossman (Prior) on May 29, 2007 at 23:19 UTC

    It's a question of intent. If your goal is to ask an object to take the "grep" action on a thingie and give you the result, you use a method call. If your goal is take a specific (global) action "grep" against a thingie and an object which you assume is an array (where the grep action indicates that it will do what it can to make it's argument an array and if it can't it will fail) then you use the function syntax.

    Forget "grep" for a moment and imagine i'm providing you a a library that implements a "dothat" function. If you want to execute my "dothat" function against objectA and objectB, you call the funtion. If objectA says that coincidently it has a "dothat" method and you want to ask objectA to "dothat" to objectB you call the method.

Re: [Perl 6] Method call versus function call on a data set
by chromatic (Archbishop) on May 30, 2007 at 00:21 UTC
    What if the datatype we are using overloads any of those, but we want to be sure we always use the standard grep?

    This probably isn't any comfort, but Perl 6 supports MultiMethods, so get used to looking at invocant types!

Re: [Perl 6] Method call versus function call on a data set
by wjw (Deacon) on May 30, 2007 at 02:20 UTC
    I have to agree with the sentiment (discomfort?) described. I am uncomfortable with the idea of my 'container' doing anything other than 'containing'. I like the idea of my array simply being an array in which I can store things.

    For me, this is analogous to putting a can of peas into a (container) pan, and having the pan heat them up for me. I don't want a pan that heats, I have a stove to do that for me. I want the pan to hold the peas until I decide to put them elsewhere. Of course, we have now had electric pans for some time, and I have learned to use them (rarely) and find them handy (also rarely). I prefer to leave my stove plugged in, and not have to plug(unplug) my pan. Sometimes simpler is better. I rarely need to move the stove, but often need to move the pan, and if the darn thing is plugged in, I may end up burning myself!

    Perhaps this is silly..., so be it. I don't want my array to be smart. (nothing against those who do want that though)

    I like that Perl gives me the ability to state what I have, the form that it is in, and allows me to do with it as I wish, rightly or wrongly. It has nouns and verbs and I can write my sentences and paragraphs as I see fit. I do not like the idea of someone handing me a paragraph (object) and telling me I now have to mold that paragraph to fit my context or intent. I find that limiting and typical of the OO code that I have dealt with.

    I am however eternally grateful to those that have written those numerous modules that I make use of, most all of which are OO.

    Thanks for the thoughtful post and responses. Enlightening as always...

    • ...the majority is always wrong, and always the last to know about it...
    • The Spice must flow...
    • ..by my will, and by will alone.. I set my mind in motion

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (5)
As of 2014-07-26 07:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (175 votes), past polls