Well. I think for things like this you need to be flexible. In this particular case, the error catching that BrowserUk and others discuss is particularly important as (fwict) Spreadsheet::ParseExcel uses OLE to talk to the Excel com server object and that this type of code is vulnerable to error outside of the scope of your own code. However your question

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]

In fact this touches on what is one of my little pet peeves about Perl. For all intents and purposes this style (which has to be deliberately enabled by the class author) is a replacment for a with statement, without the error catching opportunities of a proper with block. If a real with() was available I would personally say to avoid this style and use the with, but absent that construct I see no reason for the style not to be utilised when error catching through return value isnt a serious issue (such as when using dumper).

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....