Perhaps you’re right, I guess I like functions where the types are helping to document the function. This, again comes from Python where we type hint and rarely use multiple dispatch. I should re-think my Julia style.
This is something I’ve definitely learnt today.
edit:
Just to round off this discussion, what is the Julia equivalent of this python?
Seeing that you’re trying to calculate future salaries, this is something that I implemented a while ago. My solution was just to use a couple of functions. I don’t have the exact code I used but it was something like this
isperc(x) = 0 < x < 1
new_salary(N, x) = isperc(x) ? N*(1+x) : N + x
Here, the raise amount could be a decimal (percent/100) percentage or the total amount (like $2000). This makes the assumption that all total dollar values would be more than $1 though.
Interesting so you took a third approach. I think all this comes under the umbrella of coding style, perhaps I’m over-exuberant with multiple dispatch.
In Julia you cannot make subtypes of concrete types — all concrete types are “final”. (This turns out to be crucial for performance!)
You can make a subtype of an abstract type like Real or Number, but then it is a lot more work — the generic Real type doesn’t have definitions for basic operations like * (how could it?). For a relatively simple example defining a new number type, see e.g. Quaternions.jl.
If you are processing data, rather than relying on multiple dispatch later on, just make sure your data is conforming before doing any calculations. For the example you gave earlier, rather than having functions that do x * (1 + change) or x * change, I would make sure that all of my “change” data points (eg. in a DataFrame column) were in gross percent (90% = 1.9). Then I know x * change is going to be fine.