| About OCLFactory Interface [message #38515] |
Tue, 25 September 2007 10:12  |
Eclipse User |
|
|
|
Originally posted by: alu2526.etsii.ull.es
Hi Christian,
I had been making some mistakes, because i was instinctively using
EcoreFactory (OCLEcore metamodel) in order to create OCLEcore instances, and
i have realized that i should have used OCLFactoryImpl (which use the
EcoreFactory (OCLEcore metamodel) generated) via de
EcoreEcore.getOclFactory() method. But analyzing the interface and the
implementation, i have been a little stucked in way of use of generics.
|
|
|
| Re: About OCLFactory Interface [message #38581 is a reply to message #38515] |
Tue, 25 September 2007 10:39  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Adolfo,
The OCLFactory interface follows EMF's pattern of using generic operation
signatures for the factory methods instead of a generic type declaration.
The problem you are having is that you want to assign the result to a
variable of a specializing type, so Java's automatic type inference breaks
down and you have to use some truly bizarre syntax to tell the compiler
what the generic binding should be.
It's much more readable if you do this:
import org.eclipse.ocl.expressions.Variable;
// ...
Variable<EClassifier, EParameter> var = oclFactory.createVariableExp();
which has the added benefit of using the generic AST API instead of the
Ecore-specific implementation. I like to encourage the use of the generic
API especially because I hope that most people's OCL applications would
benefit from being able to target both the Ecore and UML metamodels (and
whatever else may eventually be contributed as bindings for OCL). If your
application does this:
Variable<C, PM> var = oclFactory.createVariableExp();
then it can target UML with little additional effort (mostly testing, I
hope).
Anyway, it may be a nice idea to specialize the OCLFactory interface in the
Ecore and UML environment implementations to narrow the return types and
remove the generic signatures, for clients that really do want to be bound
to the Ecore implementation. I just keep hoping that they will actually
want to be generic.
Perhaps you'd like to raise an enhancement request and contribute the Ecore-
and UML-specific OCLFactory interfaces?
Cheers,
Christian
Adolfo S�chez-Barbudo Herrera wrote:
> Hi Christian,
>
> I had been making some mistakes, because i was instinctively using
> EcoreFactory (OCLEcore metamodel) in order to create OCLEcore instances,
> and i have realized that i should have used OCLFactoryImpl (which use the
> EcoreFactory (OCLEcore metamodel) generated) via de
> EcoreEcore.getOclFactory() method. But analyzing the interface and the
> implementation, i have been a little stucked in way of use of generics.
> Should not be the interface generalized and, in its implementation
> specifing its generic parameters ?.
>
> A noob circumstance is that it's the first time that i encounter de
> generics
> declaration before the return value of all these methods. Finally i
> discoverd how to deal with this (i had some typecast problems, because the
> params had not been specified), but the code looks horrible. For example:
>
> Variable var = (Variable) oclFactory.<EClassifier,
> EParameter>createVariableExp();
>
> Besides, when coding, i cant have idea about the kind of the parameter
> that the method is expected to receive because the editor shows an error
> that Variable<Object, Object> cant be typecasted to Variable, so i have to
> go the class or to the interface, in order to know about the kind of
> parameter that
> the creation methods of the OCLFactory expect. Another point of view, is
> that since we are dealing with a specific Ecore Metamodel, its OCLFactory
> implementation should not continue dealing with generics, should it ?
>
> Greetings,
> Adolfo.
|
|
|
|
Powered by
FUDForum. Page generated in 0.34084 seconds
Home