One risk you run with the condensed form is that if you get a failure, you make it harder to debug the cause. That is to say, if your code is much more than a throw away, you probably should be doing something like

my $parser = Spreadsheet::ParseExcel->new() 
    or die "Some error text";
my $book = $parser->Parse($filename) 
    or die "Some error text";
[download]

Of course it may be that there is no chance that the first step will fail if the preceding use Spreadsheet::ParseExcel; statement succeeded, but that will depend on the module. If this is the case, then I would probably do away with the intermediary and go with

my $book = Spreadsheet::ParseExcel->new()->Parse($filename)
    or die "Couldn't parse file: $filename";
[download]

Unless that module Carps or Croaks under these circumstances.

Of course, if one wants to avoid naming an extra variable, a do BLOCK is the logical choice and doesn't even necessarily reduce readability:

my $book =
    do { Spreadsheet::ParseExcel->new() or die "Some error text" }
    ->Parse($filename) or die "Some error text";
[download]

Makeshifts last the longest.

If you formatted that as

my $book =  do { 
    Spreadsheet::ParseExcel->new() 
    or die "Some error text" 
}->Parse($filename) 
    or die "Some error text";
[download]

I might agree with you :^).

---

Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

Ah, good point about testing for an error in the constructor. I've got an or die... clause following the Parse call in the actual code, though I omitted it for simplicity's sake in the example above. But I suppose you're right that if Spreadsheet::ParseExcel->new() returned an invalid object reference for some reason, then that would bungle up the method call and generate an error that might not be very obvious.

        $perlmonks{seattlejohn} = 'John Clyman';

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

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.

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.

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';

I'm wondering if other monks approve of this condensed form, or if it seems awkward or might have undesirable side effects I haven't considered. Thoughts?

if considered from the POV of using pure perl objects who do not return errors via the functional interface it is not at all a bad thing. It has for instance been the recommended way of using Data::Dumper for the past ages...

my $dump=Data::Dumper->new([$foo,$bar])
                     ->Names([qw(foo bar)])
                     ->Purity(0)
                     ->Terse(1)
                     ->Useqq(1)
                     ->Indent(0)
                     ->Dump();
[download]

For the paranoid, wrapping this construct in an eval{} would provide a clean way to catch the errors.

--- demerphq
my friends call me, usually because I'm late....

I absolutely agree on the with-block issue. Something like the multiple method calls against the same object (f.ex GUI programming) snippet I've written for myself is a useful crutch for these cases, but it's still a crutch. I wish there was a better way to deal with this.

Makeshifts last the longest.

Interestingly it has been pointed out to me that for() can be used as a with, but it doesnt quite do it for me...

for ($some->{complex}[$object]{that}{we}[$need]{to}[$use]) {
  $_->foo;
  $_->bar;
}
[download]

And a proper with construct allows the compiler opportunities to optimize far beyond what any other solution allows as it explicitly states that the object will be immutable for the duration of the with. *sigh*

:-)

--- demerphq
my friends call me, usually because I'm late....

    $parent -> Button (-text => 'Quit',
                       -command => sub {Tk::exit}) -> pack;
[download]

Both the Button method and the pack method return an object (the same one actually), but if you don't need to use the widget anymore, it's often discarded.

Abigail