On Fri, Dec 03, 2004 at 06:43:05PM +0000, Herbert Snorrason wrote: : This whole issue kind of makes me go 'ugh'. One of the things I like : best about Perl is the amazing simplicity of the <> input construct. Hmm. while (<>) {...} for .lines {...} Looks like a wash to me. : Replacing that with something that not only is object oriented, but on : top of that also LOOKS object oriented is bound to be a loss. It's : going to be that bit longer to write, and not the least bit easier to : understand. Really? I dare you to show those two lines to any random computer-literate but non-Perl-speaking stranger and see which one they understand better. And actually, .lines *wins* on keystrokes if you count shift keys. : Neither the conceptual "input operator" nor the extremely : handy idiom for "behave like a Unixy filter" should go. Please. It's all cargo cult at that level anyway, so whether it looks OO or not is really completely immaterial to its usability. If .lines loses out, it won't be because of any of your arguments, but because $*ARGS maybe shouldn't be the topic of Main. But $*ARGS is most certainly an object of some sort, whether or not we hide that fact from the cargo culters. : If you don't like the angles doing it, by all means take them. But : don't push that far into OO land. There's a reason we aren't all using : Python and Ruby by now. Sounds to me like you're just allergic to dots. And I don't buy the nuclear blackmail argument either. I'll start worrying about people switching to Python and Ruby when those languages get a clue about how natural languages work. As far as I know, there's little notion of topics in those languages as of yet. (Though I wouldn't be surprised if other languages eventually adopt our "invocantless" .foo notation. For the price of one character, we document exactly which functions default to $_. In Perl 5 you just have to memorize the list.) But as I say, I'm not yet convinced $*ARGS should be the topic. It would only be the topic outside of the main loop, and people would wonder why .lines gives them a different answer in another location. That's the real problem with it. So you'll probably get your wish of some non-OO-looking syntactic sugar. Might even just be a global multi sub that defaults to $*ARGS: multi sub *lines (IO ?$handle = $*ARGS) {...} multi sub *lines (Str $filename) {...} multi sub *lines (IO @handle) {...} multi sub *lines (Str @filenames) {...} Then the filter call would be quite hypoallergenic: for lines {...} Interestingly, though, you can also call it as $fh.lines if you like. Or even if you don't. LarryThread Previous | Thread Next