DOM-Model: Overriding @Convert with incompatible return types

In DomElement method getMyParameter() should be annotated either with

1)
@Convert(String.class)
GenericAttributeValue 2) @Convert(MyConverter.class) GenericAttributeValue depending on another attribute value. The only solution I found would be to use GenericAttributeValue (w/o @Convert) and write a ResolveConverter and do all the stuff there, returning String or PsiMethod. I'd rather want to use TypeChooser and return corresponding implementation class (1) or 2)) with correct annotation and return type, but then I have to mark getMyParameter() with GenericAttributeValue]]>. All my tries ended with StackOverflowExceptions.

Does anyone have another proposal? Is it possible at all?

Thanks
Yann

5 comments

Can't you use the second case and return null if you mean String? And if
it's null the client may use getStringValue().

In DomElement method getMyParameter() should be annotated either with

1)
@Convert(String.class)
GenericAttributeValue<String>

2)
@Convert(MyConverter.class)
GenericAttributeValue<PsiMethod>

depending on another attribute value.

The only solution I found would be to use

GenericAttributeValue<Object> (w/o @Convert)

and write a ResolveConverter<Object> and do all the stuff there, returning String or PsiMethod.

I'd rather want to use TypeChooser and return corresponding implementation class (1) or 2)) with correct annotation and return type, but then I have to mark getMyParameter() with GenericAttributeValue<Object>. All my tries ended with StackOverflowExceptions.

Does anyone have another proposal? Is it possible at all?

Thanks
Yann

0

That would be a possibility, yes.

But my favourite approach would be 2 business objects as I might add more differences in behaviour and/or property types.

0

That would be a possibility, yes.

But my favourite approach would be 2 business objects as I might add more differences in behaviour and/or property types.


I can't suggest anything other for now. This is not very simple case,
and DOM usually is used to deal with simple ones. If you invent anything
suitable, we'll try to implement it.

0

digging this up again.. it seems DomExtension might be the way to go?

0

digging this up again.. it seems DomExtension might be the way to go?

Maybe. If you don't want to access your GenericDomValue<> from code at
all (at least in an easy way), and want to just have references in an
appropriate place. Then you should remove your static interface getter
and create a dynamic child in DomExtender

0

Please sign in to leave a comment.