[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2t-dev] [backend] bugs and thoughts
|
Laurent,
Ok, didn't understand the purpose of the SequenceExpression correctly
(hence point 3). As for the "if - else if - else" case, I think the
correct way of implementing it is indeed to create IfExpression with
another IfExpression as the "else".
Yes, that is one way to do it - another (especially for long cascades)
is to use a SwitchExpression, it supports having a boolean expression
instead of a value for each case.
2) This might be the most annoying one I have faced since so hard to
track down : When using a CompositeTypeSystem, getting functions from
a java file through MiddleEnd#getFunctions() fails in NPE with the
root being the first line of JavaBeansType#init() :
- _superTypes = Collections.singleton
(ts.getRootTypesystem().findType (_javaClass.getSuperclass()));
It so happens that one of the java class as no superClasses, thus
_javaClass.getSuperclass() returning null and the execution failing
later on. I have had to completely comment out all of the lines of
CompositeTypeSystem that references the field _javaBeansTypesystem in
order to get rid of the error (I do not need the java beans types for
my use case ... why didn't you create a typeSystem for java beans as
you did for EMF, one that can be registered if needed and that isn't
used otherwise).
I do not understand this yet, but it vaguely sounds as if you are
using things differently from the way I intended them to be used. If
you send some code or explain some more, I will be happy to look into
it and advise you.
The reason why the Java type system is built-in is that Java is the
only language to actually implement "native" functions, and it is used
internally. This may not be necessary at some time in the future - but
that should be transparent, and there should be no situation when it
actually gets in the way - at least that's what I hope and intend ;-)
Sorry, seems my explanation wasn't clear enough. Here is a very small
unit test case that should throw the exception I mentionned. Note that
no exception is thrown when we do not register the EMFTypeSystem ... and
yet it is no longer thrown when the java beans typesystem is commented
out. As I said earlier, this exception was a hell to track down in order
to be able to carry on my testing. As a side note, you might need to
take a look at the patch I attached on bugzilla
https://bugs.eclipse.org/bugs/show_bug.cgi?id=225565 for this snippet
not to fail before even executing this far.
public class MiddleendTest extends TestCase {
public void testFailure() {
final CompositeTypesystem typeSystem = new CompositeTypesystem();
typeSystem.register(new EmfTypesystem());
final MiddleEnd middleEnd = MiddleEndFactory.create(typeSystem,
null);
/*
* We have no middle end registered for "xfdg" files, this isn't
an issue here since failure happens before we
* even search for a middle end while registering types.
*/
final FunctionDefContext functionContext =
middleEnd.getFunctions("void.xfdg");
}
}
That was actually a bug in the JavaTypeSystem that was triggered by
syslib - and EmfTypeSystem made it appear by throwing an NPE. Thanks for
pointing it out - the fix is in CVS.
Would you view such assignment compatibility as a part of a type
definition, introducing static dependencies between the types? Or
would you see it as something introduced by a certain compilation
unit, giving it a limited scope?
I must admit I don't get your last suggestion quite well. As for the
first, this seems promising, something like a "convert" method on the
interface BackendType which would allow us to tell the backend how to
effectively convert objects of a given type to (and from) ours would
likely be enough for most conversion needs.
I get the idea. I spent some time thinking this through. Before I
explain my thoughts, could you give me a practical example of what you
would want to use the feature for? Is that something that could be done
by subtyping one of the built-in types?
I see three potential ways to supplement BackendType:
* add "convert from" functionality, i.e. allow a type to provide
implicit conversions *to* it.
* add "convert to" functionality, i.e. allow a type to provide implicit
conversions *to* it.
* add both of the above.
Either of the first two is insufficient to implement full assignment
compatibility of a newly created type with one of the built-in ones -
the built-in type would not be modified, and one of the two directions
of conversion would be barred.
The third alternative introduces redundancy and therefore potential for
inconsistencies.
Which would you prefer? What are your thoughts?
And anyway, would you care to point me to some material about your type
system etc.? That would be helpful reading to understand and anticipate
your future needs.
There are strong consequences for implementation and performance, but I
will elaborate on these when I have your response.
I wound up defining an IntegerType, the syslib's functions for it as
well as modifying the LongType to allow assignment-compatibility from
Integer on it so that I could test the backend further... this will
obviously be a blocking issue for us, is there any plans from your side
to create the missing primitives (int, float, char, ...)? I think this
would also maker the JavaBuiltinConverterFactory obsolete.
It was a conscious design decision to provide only Long and Double as
numerical types. This was done in part to be compatible to OCL which
(AFAIK ;-) ) has only these two types.
I see no real problem with adding support for all Java types. But I am
curious - could you explain the context for which you need these things?
Thanks for your efforts!
- Arno
--
Arno Haase
Langemarckstr. 16
53227 Bonn
Mobil: +49 160 98525085
Tel: +49 228 9654443
Fax: +49 228 9654448
Attachment:
signature.asc
Description: OpenPGP digital signature