Re: chaining method calls

I am not a fan.

Consider this code:

use HugeObject;
my $result = 0;

{
  my $object = HugeObject->new();

  $result = $object->get_even_bigger();

  $object = undef;
}
# Phew, should free up memory now.

if ($result) {
  # code here
}
[download]

As the object was created inside the {} it should go out of scope and the memory should be cleared - a good thing. However as object returns a reference to itself it is not cleared, and stays in memory.

If the object had just returned true or false this would not be a problem.

This may not be a problem if you read the docs for HugeObject but why add the compication for some slightly shorter code?

--tidiness is the memory loss of environmental mnemonics

Comment on Re: chaining method calls Select or Download Code

Replies are listed 'Best First'.
Re^2: chaining method calls by adrianh (Chancellor) on Jun 12, 2003 at 10:16 UTC
If it's a method that is intended to return a boolean result then I would return a boolean. I only use chaining on methods that don't return a result. If a false result is intended to indicate an error, I would throw an exception instead - so I wouldn't need to store `$result`. For the style of code I write this problem wouldn't be an issue. (also, the `$object=undef` is redundant. It would be collected at the end of scope regardless.)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: chaining method calls
by adrianh (Chancellor) on Jun 12, 2003 at 10:16 UTC

If it's a method that is intended to return a boolean result then I would return a boolean. I only use chaining on methods that don't return a result.

If a false result is intended to indicate an error, I would throw an exception instead - so I wouldn't need to store $result.

For the style of code I write this problem wouldn't be an issue.

(also, the $object=undef is redundant. It would be collected at the end of scope regardless.)

[reply]
[d/l]
[select]