Of course, it should be a string. However ‘File’ object is a better example that favors OOP. When you call ‘.read’ on a file object, you expect its content. It doesn’t matter if it’s a windows file, unix file, an IO string, or a web resource. When you call ‘.read’, it just work. Whereas in the functional world, you’ll have to 4 different ‘.read’ function calls with an if statement.
A good language for functional programming provides parametric polymorphism via traits or typeclasses:
pub trait Read {
fn read(&mut self, buf: &mut [u8]) -> io::Result<usize>;
}
impl Read for std::fs::File { /* ... */ }
impl Read for String { /* ... */ }
pub fn read_kilobyte<R>(r: R) -> io::Result<Vec<u8>>
where R: std::io::Read {
let mut buf = vec![0u8; 1024]; // vector of 1024 0s
let nbytes = r.read(&mut buf[..])?;
buf.truncate(nbytes);
Ok(buf)
}
let kb1 = read_kilobyte(File::open(...)?)?;
let kb2 = read_kilobyte("foo bar baz quux".to_string())?;
I mean, I don't see anything horribly functional-language-specific about your trait example.
Traits are not functional-language specific except in that they are often used in FP to solve problems similar to those one might use inheritance to solve in OOP.
I fear I've slipped somewhat into OO habits by using Go interfaces.
> Whereas in the functional world, you’ll have to 4 different ‘.read’ function calls with an if statement.
You could do this but that's not idiomatic.
What you would preferably do is have a function that takes a read function as a parameter. This is essentially the same thing as what OO languages implicitly do.
For an example of generic functions you can take a look at map or fold/reduce. You'll see they don't need to use if statements in the way you described.