In any case where you would do copy-paste programming, you could just use the @def macro from here <http://stackoverflow.com/questions/37358528/julia-structuring-code-with-many-different-but-related-algorithm-choices>, and then you just place the code you would want to paste around as
@def nameit begin # Code end and then you can paste that code at (compile time) using @nameit. If you want have the same fields everywhere, you can put those fields all in an @def to paste them around with @cat_sharedfields. Or you could define all of the types within a macro, looping throw a dictionary of shared fields to place them in before the non-shared fields. Checkout Base or RMath for ideas on how to do this: in Base there are many cases where macros are used to define many related functions at the same time. So yes, macros are what you're looking for. On Saturday, September 3, 2016 at 6:25:29 AM UTC-7, lars klein wrote: > > 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. > >
