inheritance:extends overrides xs:extension base

[highsource]

inheritance:extends overrides xs:extension base

[highsource]

Why shouldn't inheritance:extends override xs:extension if you
explicitly specify it?

On Mon, Dec 14, 2015 at 3:54 PM, krokodylowy [email protected]
wrote:

If binding is extended with inheritance:extends=someClass then someClass
overrides
mainClass defined in element with xs:extension base=mainClass

If binding contains xjc:superClass name=someClass then behavior is correct
and
mainClass from xs:extension base=mainClass is not overriden by someClass
(someClass is added only to class without extends)

—
Reply to this email directly or view it on GitHub
#43.

[krokodylowy]

Because xjc:superClass doesn't do it. I tried use inheritance:extends as replacement but it's dangerous.
Super type declared in xs:extension is ignored

[highsource]

inhertitance:extends is not meant as a replacement for xjc:superClass. Why should it be if you have xjc:superClass?

It is predictable and deterministic in what it does, so not exactly fits in my understanding of "dangerous".

[krokodylowy]

Why should it be if you have xjc:superClass
No. If I remove xjc:superClass and include inhertitance:extends results can be different
in java class code at line with 'class x extends y'

BTW.
I found it as workaround for #42. Code with xjc:superClass doesn't generate correct clone,hash and equals but inhertitance:extends do it correctly.

[highsource]

I'm inclined to close it as it is works as designed. inheritance:extends will make the generated class extend the given class, no matter what.

If you really need the functionality "don't force extends", I'd see it as another issue. But I'd really like to know why it is needed. The only thing I can imaging is if you're using a mulinode XPath select in the binding to apply the customization to many nodes at once.