Performance of chained methods.

Daniel Walmsley daniel at landmarksoftware.com.au
Tue Oct 29 23:38:08 CST 2002


As soon as one procedure returns undef, the subsequent call will fail, and
the failure will chain back down without reaching out to the end. I think.
That is:
Example 1:
1) FirstMethod works
2) AnotherMethod fails, returns undef
3) Perl barfs when asked to call MoreMethods
4) You return undef

Example 2:
1) FirstMethod fails
2) Perl barfs when asked to call AnotherMethod
3) You return undef

Therefore I don't see it as being any less efficient than any other way,
UNLESS Perl is automatically breaking it into separate statements with
separate return values without treating it like one big "block" that can die
at any step and return.

Whoops, I guess I just failed to answer your question. Bugger it, I'll hit
send anyway.

As to whether it's "bad practise", I guess it depends on whether anyone who
cares about that sort of thing is ever going to look at your code again ;)

Dan

-----Original Message-----
From: Scott Penrose [mailto:scottp at myinternet.com.au] 
Sent: Wednesday, 30 October 2002 2:48 PM
To: melbourne-pm at pm.org
Subject: Performance of chained methods.


Hey Dudes.

I have a bit of code that looks like this

	my $ref =  
SomeClass->FirstMethod($param1)->AnotherMethod($param2)->MoreMethods();

Perfectly legitimate in that we are effectively getting a grass root  
element and drilling down.

My problem is that each of these can fail. In my particular case I  
don't care which fail or why, is it ok therefore to do this

	my $ref = eval  
{SomeClass->FirstMethod($param1)->AnotherMethod($param2)- 
 >MoreMethods();};
	return undef if ($@);

Or is that a really bad practice?, is there a better way ?, otherwise I  
have to fall down to the usual practice of one at a time.

	my $obj1 = SomeClass->FirstMethod($param1)
or return undef;
	my $obj2 = $obj1->AnotherMethod($param2)
		or return undef;
	my $ref = $obj2->MoreMethods()
		or return undef;

Scott

-- 
Scott Penrose
Welcome to the Digital Dimension
http://www.dd.com.au/
scottp at dd.com.au

Dismaimer: Contents of this mail and signature are bound to change  
randomly. Whilst every attempt has been made to control said  
randomness, the author wishes to remain blameless for the number of  
eggs that damn chicken laid. Oh and I don't want to hear about  
butterflies either.




More information about the Melbourne-pm mailing list