But somehow, I see too much "plain" code around. Code that accesses these data structures directly, assuming their implementation is fixed.
I'd argue that Perl's powerful standard data structures are a good thing and using them "plainly" is usually the best option. The semantics and syntax are well-known. You can look at someone's code, see $values{one} = "somevalue", and almost always know exactly what that will do (of course things are a bit more complicated with tie in the picture, but let's just ignore that for now).
If everybody always abstracted this kind of thing away in a function, that certainty would rapidly disappear. Sure, you could reasonably assume that store_value(one => "somevalue") is doing something very hash-like. But why should people have to assume, when you can use the direct approach and ensure they will know?
In my opinion, such code will be much more understandable, easier to debug and more fun to write.
Perhaps this would make Perl easier to understand and more fun to write for Lisp programmers, but hashes are fundamental things to Perl programmers. They do not usually need to be abstracted away. When they do, it should only be for a good reason. I have to wonder if you would also rather we avoid using scalars and arrays directly, because they could be abstracted into functions that do the same thing?
In reply to Re: Using functional abstraction in Perl
by revdiablo
in thread Using functional abstraction in Perl
by spurperl
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |