Re^2: Prototype mismatch: sub main::trim: none vs ($)

Excellent point on bringing attention to the prototype!

... those three functions will not behave like most other subs you'll use (at least the ones from other modules). To avoid surprises, you should remove the ($) after the names of your subs.

I think a trim function would make sense as a unary operator, that would put it in the same category as lc, lcfirst, uc, ucfirst, fc, length, chr, hex, oct, int, ref, scalar, and quite a few more. But this is definitely another one of those "do this only if you know what you're doing and why" cases. (Just the other day there was a thread on the same topic.)

Regards,
-- Hauke D

Comment on Re^2: Prototype mismatch: sub main::trim: none vs ($) Select or Download Code

Replies are listed 'Best First'.
Re^3: Prototype mismatch: sub main::trim: none vs ($) by Eily (Monsignor) on Feb 08, 2017 at 14:56 UTC
I agree on the fact that a trim function could make sense as an unary operator. I think the problem is mostly that this was not documented, although the code seems to be meant to be shared. Personally though, I prefer only using the special case of the & prototype, where the special block syntax would be invalid without the prototype, removing the need to know how the function was declared to read a statment correctly.	[reply]

Replies are listed 'Best First'.

Re^3: Prototype mismatch: sub main::trim: none vs ($)
by Eily (Monsignor) on Feb 08, 2017 at 14:56 UTC

I agree on the fact that a trim function could make sense as an unary operator. I think the problem is mostly that this was not documented, although the code seems to be meant to be shared. Personally though, I prefer only using the special case of the & prototype, where the special block syntax would be invalid without the prototype, removing the need to know how the function was declared to read a statment correctly.

[reply]