CompositeStructs.jl
CompositeStructs.jl copied to clipboard
marius311
parent type copy constructors
This is a quick proof of concept for issue #7. As far as I can tell it works fine, but I haven't tested any edge cases. No documentation or testing yet.
Just took a look at it, this idea makes a lot of sense to me, thanks! If you can add tests and a note in the readme I'll merge.
This seems to break the readme example fyi, which you may have seen and I'm sure is fixable.
Ok, I've fixed the basic issue with parametric parent types (which was actually a bit stupid). The two different constructor generation parts could be combined and simplified a bit, but I left them separate for now.
I'm now running into a strange error in line 118 of runtests.jl, will keep investigating.
@marius311 the problem seems to be that now that the macro always returns a struct plus the new "copy constructor", outer @kwdef breaks (as it expects just a struct as input). As far as I can see the only way to fix this would be to only generate the constructor in the (inner) kwdef case which doesn't make a lot of sense. So, I think it boils down to choosing one of two functionalities - outer kwdef or copy constructors. Personally, I would ditch outer kwdef, but it's your package.
Hmm, this got me thinking about the wider conceptual issues with my PR. So far @composite is strictly orthogonal to struct definition. The output of the standard version behaves exactly as you would expect from a plain struct declaration. In particular which constructors are or aren't generated follows exactly the same rules irrespective of whether you use @composite or not (with or without @kwdef). With my PR this is no longer the case. For example, if a user defines an inner constructor a) there will still be an outer constructor (contrary to expectations) and b) the "copy constructor" might simply break if the inner constructor has a different argument list than the default constructor.
All of this is true for Base @kwdef as well, of course, so one might argue that this is not a problem, but at the very least it is a design decision to be made.