defshout(x)
# Notice that both Int32 and String respond_to `to_s`
x.to_s.upcase
end
foo = ENV["FOO"]? || 10typeof(foo) # => (Int32 | String)typeof(shout(foo)) # => String
So, static duck typing?
I mean, if this can provide the dynamic typing crowd 70% of the rigidity of a more explicitly typed language, I’m all for it, but from an explicit static typing viewpoint, I don’t see the benefit.
If you write a method and don’t document what data types the parameters take, I hate you.
And duck typing is basically just a way to skip writing a trait/interface, which means you can’t specify the type, because you don’t have a name for it, which means I hate you.
I mean, the compiler will figure out a type which an IDE could display, but it’ll be a humongous union type and it’ll only contain what data types currently get stuck into there, not what other data types I can stick into it.
def shout(x) # Notice that both Int32 and String respond_to `to_s` x.to_s.upcase end foo = ENV["FOO"]? || 10 typeof(foo) # => (Int32 | String) typeof(shout(foo)) # => String
So, static duck typing?
I mean, if this can provide the dynamic typing crowd 70% of the rigidity of a more explicitly typed language, I’m all for it, but from an explicit static typing viewpoint, I don’t see the benefit.
If you write a method and don’t document what data types the parameters take, I hate you.
And duck typing is basically just a way to skip writing a trait/interface, which means you can’t specify the type, because you don’t have a name for it, which means I hate you.
I mean, the compiler will figure out a type which an IDE could display, but it’ll be a humongous union type and it’ll only contain what data types currently get stuck into there, not what other data types I can stick into it.