That is a separate issue. If you are writing a module that you want to support subclassing of and you have a function that you want to allow to be overridden, then you should probably just make it a method.

But it is perfectly reasonable to write a module that you want to support subclassing of but that uses utility functions that should not be overridden because they are tied to some current implementation detail that you might want to change later without breaking current subclasses.

A separate issue is whether you want subclasses to be able to conveniently call this function. The previous solution accomplishes this but doesn't allow for overriding, which is probably the right solution for some cases.

Perl is a bit strange for a language that supports OO in that it provides no features for separating the details of your module that 1) are implementation details that you want to keep completely to yourself so that you can create a new version that improves some things without breaking other people's code, 2) are suitable for use by a subclass, 3) are suitable to be overridden, 4) are to be used when the module is used.

This, however, does not mean that every single detail of your module should be in (3).