Cleanup - remove unused parameter with magic numbers

[happy-barney]

NewOp's first parameter is unused since 2007, polluting codebase with magic numbers.

PR is adding new macro NewOp_v542 without this unused parameter.

Macro name is also POC of adding Perl version when macro will be added to maintain reasonable
backward compatibility by version string in symbol name.

[iabyn]

On Sat, Dec 21, 2024 at 01:05:22PM -0800, Branislav Zahradník wrote: PR is adding new macro `NewOp_v542` without this unused parameter. Macro name is also POC of adding Perl version when macro will be added to maintain reasonable backward compatibility by version string in symbol name.

I can't see what practical gain you get by including the version number in the new macro. It just seems to make it worse.

…

-- Modern art: "That's easy, I could have done that!" "Ah, but you didn't!"

[happy-barney]

I can't see what practical gain you get by including the version number in the new macro. It just seems to make it worse.

Symbol name is describes behaviour. With new version behavior changed (3 parameters instead of 4).

It's same like with humans. Look for example at French kings, there were for example:

• Louis XIV
• Louis XVI

They have version in names as well, so you can distinguish one born in 17th century and another in 18th.

Same is for this pattern - you can introduce new symbol, new behaviour and still provide old one so there is no need to modify every old code simultaneously.

[iabyn]

On Mon, Dec 23, 2024 at 04:36:25AM -0800, Branislav Zahradník wrote: > I can't see what practical gain you get by including the version number in the new macro. It just seems to make it worse. Symbol name is describes behaviour. With new version behavior changed (3 parameters instead of 4).

But the version number tells you *nothing* about the behaviour. We have a long history in perl (as do many other projects) of naming newer variants of an API function. The new name usually tries to use some sort of simple mnemonic to indicate its changed behaviour. For example: my_atof2() and my_atof3() - two- and three-arg variants of my_atof(); or av_fetch_simple() - an optimised version of av_fetch() applicable in some circumstances; or newSVsv_flags() - a variant of newSVsv() that takes an extra 'flags' argument. Is newSVsv_530() easier for a developer to understand than newSVsv_flags()? And if not, is there any other technical benefit of using the newSVsv_530() naming convention?

…

-- Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.

[happy-barney]

But the version number tells you nothing about the behaviour.

Well, difference is that I'm using release numbers and not version per symbol.
There it tells you one important thing - when it was introduced. Rest is matter of documentation.

I'm not using version to provide different behaviour with of same symbol. It will still be NewOp behaviour
with two implementations:

• as implemented before v5.42
• as implemented in v5.42

It may not tell much about actual behaviour, but it tells which version of behaviour and it ensures that it will be preserved.

Following this pattern ensures 100% forward compatibility (eg: no need to recompile XS with each release).

It will even (with some tweaks) allow to propagate newer grammar into older versions - this is root assumption behind idea of exact use VERSION - https://github.com/happy-barney/perl-wish-list/blob/master/exact-use-version/spec/spec.md