In the style guide, it talks about type piracy [1], the practice of extending or redefining methods on types you didn’t define. We’ve been told in the past not to do this, especially with methods and types defined by Base, as it can subtly break Julia. However, we are in a situation where we really…

Something like this perhaps? module Nemo export NemoType struct NemoType end Base.exp(::NemoType) = println("calling exp for NemoType") exp(x::Int) = println("calling Nemo.exp for julia type") end resutling in julia> x = NemoType() Nemo.NemoType() julia> exp(x) calling exp for NemoType julia> e…

Type piracy only applies to extending methods you did not define to operate on types that you also did not define. For example module Foo foo(::Integer) = 1 end Foo.foo(1) # 1 module Bar import Foo.foo foo(x::Int) = 2 end Foo.foo(1) # 2 The key part of this example is that Bar was adding method…

I should add that we would be exporting these functions. Certainly not import, just export. Still ok?

Yes, it is fine, but what is the gain of exporting them?

There might be a way around it in some cases, but for example, we have to export exp from Nemo, because exp is a function defined on power series, not just on the rings over which you can take power series. Also, sqrt returning a float just isn’t much use to a user of Nemo. They will want Nemo.sqrt …

Nothing of what you said explains why you need to export e.g. exp. The exp binding is already available by default since it is exported from Main.

You are right. I think you just revealed a misunderstanding I have about what export actually does.

Actually, on second thoughts, Julia has changed the name of so many of its functions so many times, I think we ought not rely on a “binding” for exp being available because of an export from Main. And who knows, maybe one day they get moved into a package, as happened with isprime, for example (this…

It still doesn’t matter because your users will qualify with module name.

Technically, yes. But for new users, we essentially rely on the ambiguity message emitted by Julia to teach new users that. Should Julia change the name of its function, users would have no idea why the function doesn’t work. I still think it is better to export it, and I don’t see any down side.

Clarification on type piracy

General Usage

kristoffer.carlsson September 16, 2017, 7:50pm 3

Having local implementations is not type piracy, see the “extending or redefining” part.

Even more clarification on Type piracy

Topic		Replies	Views
Even more clarification on Type piracy New to Julia package , type , type-piracy	24	4049	January 6, 2022
Minimal working example that demonstrates the danger of type piracy General Usage question , type-piracy	9	1161	August 24, 2021
How to detect/avoid type piracy? General Usage	77	3099	June 14, 2024
Is dispatch on another type's parameter (::NotMyType{MyType}) piracy? General Usage	32	967	May 29, 2024
Julep: Taking multiple dispatch,export,import,binary compilation seriously Internals & Design namespaces	120	9860	May 18, 2018

Clarification on type piracy

Related topics