Add manual section on method design and more advanced ambiguity resolution

[timholy]

I think many people struggle with how to resolve ambiguities, and this really gets into how one should design Method hierarchies in Julia. For some time I've thought we could use a bit more documentation on this topic; here's an attempt to start that conversation.

There are many caveats to this:

• it's surely incomplete
• it ventures opinions that may or may not be defensible
• it may not be in the right place (it may make use of some concepts not yet introduced)
• it may not strike the right balance (it has a feel somewhere between "high level design patterns" and something more along the lines of the cookbook approach of "performance tips")

In other words, it's just about perfect for generating discussion on the topic 😉.

[musm]

Thanks.

What's your opinion on including some of the following points or thoughts.
From steveng

my understanding is that if you write a function f(T::Type), then T is just a value that is determined at runtime (the same version of f is compiled for all values of T), whereas if you write f{T}(::Type{T}) then T is part of the type signature of the function — hence it is known at compile time and a specialized version of f is compiled for every T.

Ref 17794

This statement only apply to types if my understanding is correct? In other words, there is no difference between the following two functions
fun1{T<:Number}(x::T) = x
fun2(x::Number) = x
both will specialize upon calling the function on different subtypes of Number

[nalimilan]

I don't understand what you mean by this point.

[timholy]

That is to say, where possible don't dispatch on T, but it's OK (often necessary) to dispatch on MyArray.

[mauro3]

Note quite clear to me what you mean, maybe add example?

[timholy]

@musm, that's right. The limitation regarding types (T::Type vs ::Type{T}) may be more about where Julia is now than anything truly fundamental; in other words, I can easily see it getting to the point where it doesn't matter for types, either.

[mauro3]

Just to be on the save side, I'd write "...,the more methods a generic function has,..."

[mauro3]

Good addition, thanks for writing down your insights.

[Sacha0]

The material in this pull request is insightful. Any hope of reviving it? Thanks!

[timholy]

Comments addressed and rebased.

[tkelman]

the manual isn't in rst any more, bad rebase adding that file

[timholy]

Indeed. See #20702.

[tkelman]

would it make more sense for this to be the same padding function replicate_edges(A, size(kernel)) as above?