in reply to Re^2: Readonly vs ReadonlyX
in thread Readonly vs ReadonlyX

The author of ReadonlyX explains at length that he "improved" the API to be a "drop in replacement"

(--> https://metacpan.org/pod/ReadonlyX#ReadonlyX-vs.-Readonly)

And this aliasing of namespaces happens in his module

BEGIN { *ReadonlyX:: = *Readonly:: } package # hide from PAUSE Readonly; # I wish...

that's unfortunate to word it mildly.

Especially since the author explicitly admits incompatibilities. (quote: "break 16 years of code out there in Darkpan.")

When another module loads the original Readonly, different implementations and prototypes will collide.

This "collides" with my understanding of a "drop-in-replacement".

If you want to use ReadonlyX, force it to use it's own namespace.

If there is no option for that, file a feature request.°

Regarding the strong wording of the PC-Policy - which I also dislike for its style- I doubt it originates in PBP.

And it seems to me this module is also far newer (2016) than Damian's book (2005), so please stop referencing it as justification.

Cheers Rolf
(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)
Wikisyntax for the Monastery

°) I could also come up with a wrapper module which is fixing that by unaliasing the namespaces, but let's wait what the author says.

Replies are listed 'Best First'.
Re^4: Readonly vs ReadonlyX (bad style)
by LanX (Saint) on Mar 11, 2023 at 17:55 UTC
    > that's unfortunate to word it mildly.

    In hindsight, this is because Readonly is recommending fully qualified subs,

    Readonly::Scalar $sca => $initial_value; Readonly::Array @arr => @values; Readonly::Hash %has => (key => value, key => value, ...);

    Any "drop-in replacement" supporting this must meddle with the namespace ... ugly!

    Cheers Rolf
    (addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)
    Wikisyntax for the Monastery