in reply to Style Question: Throwaway Objects

Writing my $book = Spreadsheet::ParseExcel->new()->Parse($filename); is equivalent to writing 
my $parser = Spreadsheet::ParseExcel->new();
my $book = $parser->Parse($filename);
undef $parser;

[download]
I'd go with whichever you think reads better, or the original snippet. (I favor the original snippet, on the assumption that keeping the ParseExcel object alive for the duration of the scope has little or no measurable impact on performance or memory use.) BrowserUK nails this one. Keep the statements separate, so that you can error check them separately. If you're concerned about memory, you can always undef $parser;

Replies are listed 'Best First'.
Re^2: Style Question: Throwaway Objects
by Aristotle (Chancellor) on Dec 09, 2002 at 02:00 UTC
    Just to nitpick: you're leaving a lexical $parser around that the condensed form doesn't, so it is actually equivalent to 
    my $book;
{
    my $parser = Spreadsheet::ParseExcel->new()
    $book = $parser->Parse($filename);
}

    [download]
    or, as I'd prefer, 
    my $book = do {
    my $parser = Spreadsheet::ParseExcel->new()
    $parser->Parse($filename);
};

    [download]
    logically followed by 
    my $book = do {
    my $parser = Spreadsheet::ParseExcel->new()
    $parser
}->Parse($filename);

    [download]
    which is (and here's the important step) obviously equivalent to my $book = do { Spreadsheet::ParseExcel->new() }->Parse($filename); which is trivially equivalent to my $book = Spreadsheet::ParseExcel->new()->Parse($filename); Tightly scoping with a block instead is generally better practice. The garbage collector will clean up after you without any extra effort on your side anyway.

    Makeshifts last the longest.

[reply]
[d/l]
[select]
      Just to nitpick: you're leaving a lexical $parser around that the condensed form doesn't

      Well, yes. But compared to turning a very readable 

          my $parser = Spreadsheet::ParseExcel->new()
    my $book = $parser->Parse($filename);

      [download]
      into a double-take inducing   my $book = do { Spreadsheet::ParseExcel->new() }->Parse($filename); leaving a lexical around is a minor sin. When I have to choose between various sins, I'll go with the one that's readable.

[reply]
[d/l]
[select]
        That was just the last in a series of transformations showing the equivalence of the samples - I'd probably pick the first one: 
        my $book;
{
    my $parser = Spreadsheet::ParseExcel->new();
    $book = $parser->Parse($filename);
}

        [download]

        Makeshifts last the longest.

[reply]
[d/l]
Re: Re: Style Question: Throwaway Objects
by seattlejohn (Deacon) on Dec 09, 2002 at 01:09 UTC
    Thanks for the response, and just for the record: I'm not *that* concerned about memory. I was just reviewing some code I'd written previously looking for refactoring opportunities, redundant redundancies, unnecessary verbosity, and general housekeeping opportunities... and I found myself wondering if there would be any upside (or downside) to combining those two lines into one.

    I tend to be a stickler for testing and reporting on errors, and BrowserUk has convinced me that error-reporting alone is a good reason to keep those lines separate.

    Again, thanks!

            $perlmonks{seattlejohn} = 'John Clyman';

[reply]

In Section Meditations