type signatures

[mkborregaard]

Hi, the droptips function appears to have the signature droptips!(t::T, tips::Vector{NL}) where {NL, BL, T <: AbstractTree{NL, BL}}. But couldn't tips be any AbstractVector{NL}, or be a Set{NL}? Or a generator or an Iterator or anything else that yields something that can be interpreted as a Node?

[richardreeve]

Yes, absolutely. Good point.

[mkborregaard]

Simply delete the type signatures, and duck type on anything but AbstractTree? Or is the NL important?

[richardreeve]

#20 does switch it to AbstractVector{NL} already incidentally. We could duck type, but I'd rather wait until we have a sensible trait interface and then just put in some iterable trait. If you have a need for a Set or something that's not an AbstractVector I'm happy to switch it now though...

[mkborregaard]

I don't need a Set very much - that's just the type I naturally had in my code when I ran into this. AbstractVector{NL} is probably OK but why not just ducktype, where do you see the issue?

[richardreeve]

I'm just not a massive fan of duck typing, partly unfairly because the languages where I've used it tend to be so poorly designed (though I appreciate that's not the case here), but also because the errors when you misjudge the (now hidden) type requirements are that much more obscure as they are buried in some subsidiary function call. I'm not implacably opposed to it though - I'll sort it out.