A while ago I suggested that using attributes may be a way out of the
problems we're having with meta models. The response then was that the idea sure seemed nice, but the implementation of the idea sure seemed nonexistent.
I have now whacked together a proof-of-concept for my idea.
neat! Seems to be working :D
<snip/>
What happens if you attach an inheritable attribute to a Constructor?
IMO: it is not inherited. a call to super(/* blah */) had better still respect the attributes applying to that parent constructor, though.
I would think the real messy part is with default constructors and/or implicit calls to super():
class Super
{ /** @Blah() */
Super() { /* ... */ };
}
class Sub
{
}does '@Blah()' apply to the default constructor of Sub?
What happens if you attach an inheritable attribute to a Field?
public static class Super { protected int v = 0; } public static class Sub extends Super { protected int v = 1; }
that is, imo, pretty ugly code :D. But yes, it should be dealt with.
Fields are inherited, but not in the same way as methods, so their attributes shouldn't follow as well, or?
as long as a field definition is not overridden in a subclass, the attributes should stay:
public static class Super { protected int v = 0; }
public static class Sub extends Super {
blah() { System.out.print(v); }
}prints 0, of course. When a field definition is overridden, it is not really 'overridden', but it is *hidden*. Its attributes should stay (so that the parent class can access the attributes of its own field), but not apply to the new attribute in the subclass.
At least, that seems consistent to me. Can it be implemented, is a folluwup question :D
cheers,
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
