Is it type-piracy to define `Base.parse(::Type{Tuple}, str)`?

type piracy is a thing in julia. I am wondering whether or under which circumstances it is fine to define something like

Base.parse(::Type{Tuple}, str) = ...

i.e. a Base function for a Base Type.

Or should you better define your own MyPackage.parse which falls back to Base.parse?

You own whether type nor function, so I’d say: yes, that’s piracy.

Edit: it may still be fine, though!

1 Like

because of what might it be fine?

I’d argue that this the better solution in all cases. The main problem with defining Base.parse(::Type{Tuple}, str) is that it is a global change that affects all code everywhere. So it might cause a lot recompilation of already compiled code and that code might work incorrectly afterwards. It could break code in some other package that relies on some particular behavior of Base.parse that you alter. It is essentially impossible to ensure that you don’t cause unwanted side effects.

Defining your own MyPackage.parse has none of these effects.

3 Likes

It might be fine if you are pirating in private code and you can accept the consequences (invalidations, unexpected side effects, because you might overwrite someone else’s (also pirated!) method, etc.!).

If you commit type piracy in a public package that is supposed to form the basis of an ecosystem… that’s another story (don’t do it :slight_smile: )

4 Likes

It’s a bad idea in general. For one thing, changes to Base can make the pirated method ambiguous, so your once-good code will crash on an upgrade. This is a risk even without piracy, but piracy makes it more likely.

It’s easy to define your own parse function which falls back to Base.parse, or the equivalent for whatever function you’d like to extend. This will never become ambiguous, because your function will always be called on your code, so any new method in the package (doesn’t have to be Base or a stdlib) which would otherwise lead to ambiguity will never be called in the first place.

In other words, piracy isn’t (just) antisocial, it’s actively bad for your program. Shadowing a method is easy, do that instead, it’s always a better idea.