Creating a function from a subset of the methods of another function

lets say i have a function f with a lot methods:

julia>methods(f) #invented output
[1] f(x::Int64, y::Int64) in PackageA at \.julia\packages\PackageA\yPcDQ\src\functions.jl:43
[2] f(x::Float64, y::Float64) in Main at REPL[50]:1
[3] f(x::String,y::String) in Base at somefile.jl:456
[550]  f(x::AwesomeType, y::AwesomeType) in AwesomeTypes at \.julia\packages\AwesomeTypes \asSdS\src\awesome.jl:43

I want a function f2 defined as a subset of the methods of f from a subset of packages (for example, just Base, PackageX1, and PackageX2). for example, with the criteria above, the function f2(AwesomeType(1),AwesomeType(2)) should throw an error, but f2(1.0,1.0) should be ok.

There is any way to do this?

f2(signature...) = f(...)

Repeat for as many subsignatures as necessary.

1 Like

how can i extract the signature of f from the list of his methods?, the solution is trivial with 20 methods, but if i have 500 of them, writing by hand is infeasible, being more specific, i want to do that function programmatically, using f as base and a Package criteria.
For example, this pseudocode:

macro method_subset(fun,packages) 
f2 = gensym("subset_function") 

  fmethods = vector_of_methods($fun) 
  for i in 1:length(fmethods)
    if from_package(fmethods[i]) in packages
      $f2(signature(fmethods[i])...) = $fun(signature(fmethods[i])...) 

f2 = @method_subset f (Base, Package4, Package1)

You can call methods on it, but why do you have to? How do you want to express at a high level which signatures you want to “select”? Whatever that selection expression is, already is a single method signature, so just use that when defining f2.

1 Like

sorry, i got the pseudo code wrong. putting another (more specific) example. if f = cos and the subset is just the package Base, so something like this:

using Measurements
cos2 = @method_subset cos (Base)
cos2(1.0 ± 0.1) #not defined

Can you not do

cos2(args...) = cos(args...)
# add other methods

If you want, this function can even be called cos, you just have to qualify the other call as Base.cos.

They’re saying that they want a function which only has the methods of cos that came from Base but not (for example) Measurements.jl.

1 Like

Ah, I see. Seems like something like the pseudo code would be necessary then since it’s not a type-level restriction, it’s a question of where the methods were defined.