| [reply] |
I think I could have processed the contents of that blog post three times as fast if he had just used normal indenting.
So I went through all of that, and in the end his conclusion is "it's insanely broken because you cant use them for sort until 5.22 and "our sub" can accidentally redefine methods". So, maybe don't use "our sub", but "my sub" would seem to be perfectly fine. I much prefer to call a sub by name rather than as a function-deref notation from a lexical variable.
| [reply] |
That article uses strong words like "almost irredeemably broken", "incredibly bad idea", which I consider outright wrong.
The issues with our sub speak { ... } are rather obvious. Technically our makes "lexical" aliases, but I have never seen a use case to use our together with sub.
A different thing is my sub speak { ... }. This is what I would call a named lexical subroutine, and I use them occasionally. They work for sort since 5.22, which was released nine years ago, so shortly after brian d foy wrote his rant. And they are no longer experimental, they just work.
While it is correct that you can achieve the same goals with a code reference to an anonymous subroutine, I prefer my sub. It looks "nicer" to me, and I am not distracted by looking whether the code reference is passed to other routines in other packages.
| [reply]
[d/l]
[select] |
