|Do you know where your variables are?|
Re^2: CPAN module fior common idioms?by ihb (Deacon)
|on Jul 24, 2004 at 02:18 UTC||Need Help??|
++ for a good post.
I too wouldn't care much for a Idioms::Common module, but I sometimes would like to see libraries that performs the function the idiom does, if abstractable.
As I see it, we talk about two different idioms: functional idioms and patterns (the distiction may be a bit fuzzy). Below I will talk about functional idioms only.
I would like to bring up some of your point and elaborate a bit.
For example, how do you write a Perl5 library to handle the Schwartzian Transform? / ... / But writing a library to handle the obvious alterations would be heavier than the perceived value of having such a library.
You raise a good point, but I think you take a too black and white look and the situation. You don't have to write a library to handle any alternation. I realize that ST was just an example, but let's continue on that example. Just a plain ugly ST may do fine in many cases, and then the library version could be used (and it's easy to abstract the vanilla version). Having a library that handles one common way to do ST doesn't stop you from using your own ST.
An example of this is File::Slurp which is one of my favourite modules. It uses plain and simple routines, but often I need those plain and simple routines. When I need something more controlled I do it myself.
Another example is grep, which is a special map.
And we agree grep is a good addition to Perl. And like above: I need a more sophisticated grep I use map, but grep is still nice to have for all those cases where I just want a simple grep.
If grep wasn't built-in though, I still would've enjoyed having it ready through a library.
Instead, where appropriate, melt the powerful idioms into the language itself.
Indeed, and this is what Perl 6 is about, partly. But in the mean-time, I don't see any wrong in abstracting abstractable idioms into libraries. But there's also another side to it. Some idioms may be appropriate for you to melt into the language, but someone else might want another set of idioms into the language. The Perl 6 RFCs shows good examples of this. Or perhaps I'm twisting the meaning of idiom now and if something isn't overall applyable, then perhaps it isn't an idiom after all.
There will always be inappropriate or inconveniently persistent idioms that resist packaging: unique() and slurp() come to mind. Should they be a library? Or should they be one-liners that you can type from memory?
As it turns out, slurp() is available as &File::Slurp::read_file. It's not written idiomatic, and I'm in fact not arguing with your main point. This has nothing to do with idioms, and as I said at the very top: I don't see any reason to put the idiom in a library, but the function the idiom does.
In my observations, so-called master programmers generally don't rely on idiom libraries or pattern classes.
I believe there are a couple of factors for that:
Just my thoughts,
Read argumentation in its context!