For a toy example like this, this is reasonable advice.

But what if the cat has a huge amount of members and many types derive from cat 
?
You would have to copy and paste all the common data between all the types.
That's a problem, especially if something needs to be refactored.

Plus: There's no type safety. It seems to me, as if the functions impose some 
kind of implicit interface on the types they operate on.
How does meow know that there exists a field like age ?

It seems to me that this could lead to very hard to find bugs. Assuming I have 
a collection of cat-derivatives. Tigers, lions, panthers,...
Each of them should be able to meow. But if I have a typo in one of the fields, 
I will never notice it, until the method is used with the faulty type.

Is it possible (on the roadmap maybe) to add explicit interfaces to the 
language ?

But I think, if there are interfaces which specify fields, the implications are 
far-reaching. Specifying that a type fulfills an interface is equivalent to 
specifying the fields.
Then why not have the fields added automatically. This addresses the first and 
second issue. Copy and paste is avoided, as well as bugs due to missing fields.
But then an interface would be just like an abstract type with fields. Which is 
apparently impossible.

Could you maybe give me some more feedback on this ?
What are the limits of interfaces.

Maybe you could have a julia preprocessor that populates the types with fields ?
Although I assume that this is undesirable since it makes valid Julia code 
(valid for the actual compiler) somewhat of a second class citizen.

Is it possible to use macros to address these issues ?
I'm afraid I've never used them.
They seem incredibly powerful (@simd, @parallel).

Thanks for the great information so far.

Reply via email to