If for example, your class uses a database, the destructor would be a good place to close the connection.

If for example, your class uses a database, the destructor would be a good place to close the connection.

Yup, but DBI connections already come with a destructor that closes the connection, so :)

Another use scenario is to break circular references, but those are easily avoided with https://metacpan.org/pod/Scalar::Util#weaken

Yup, in perl, I've rarely written a destructor

Yup, but DBI connections already come with a destructor that closes the connection,

"DB" does not necessarily imply "DBI".

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

thanos1983:

Typically you only need a destructor when you're using a resource that perl can't figure out how to release automatically.

I don't recall ever needing to use a destructor in perl, but the situations I can think of are typically things like having circular references that don't get freed automatically. Generally, though, my code doesn't worry about that, because between perl and the operating system, when the script ends, all the resources will be closed and freed.

I don't have any suggestions on how to recognize when you need one--but another monk might have a few. If it were me, I'd ignore destructors until you get more comfortable with learning OOP. Once you get a good handle on it, you'll probably start to figure out when destructors make sense.

...roboticus

When your only tool is a hammer, all problems look like your thumb.