| 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.
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.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 ;-)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