Hi Niklas, On Mon, 20 Apr 2020 at 07:48, Niklas Keller <m...@kelunik.com> wrote:
> > What's more important here IMO is the restriction of inheritance, > mainly because the raw arguments are exposed via reflection and won't > be compatible between parent and child attribute in any case. > Could you explain a bit more about the problem you see here? My understanding is that the reflection API is designed to allow two usage styles: * Treating attributes as untyped mappings from a name to a list of arguments (fetch all, or filter by exact name, then call getName() and getArguments()) * Treating attributes as classes instantiated with the argument given (filter by INSTANCE_OF, then call newInstance(), formerly called getAsObject()) For the first style, inheritance doesn't matter, because the attribute name is never resolved as a class anyway, it's just an identifier (it might happen to look like one, to avoid naming collisions, in the same way XML namespaces look like URLs). For the second style, it's up to the user to provide the right arguments for the attribute they used, just as it would be if they instantiated it directly with the "new" keyword. The only case I can see where incompatible constructors would be a problem would be if someone filtered by INSTANCE_OF, and then called getArguments() and expected them to be consistent rather than using newInstance(), but I'm not sure why anyone would want to do that, so a one line note in the manual pointing out it's a bad idea would seem sufficient. But perhaps I'm missing something more fundamental that makes you feel that inheritance should be restricted? Regards, -- Rowan Tommins [IMSoP]
