| Validation to detect duplicates [message #56165] |
Tue, 07 July 2009 21:24  |
Eclipse User |
|
|
|
Hi,
I've gotten my project just about to the point I was with the oAW tools.
It definitely appears to be faster. There's certainly less memory used -
with oAW, I had to disable the outline generation in order to stop filling
the heap. (My blog post:
http://jwbito.ballardview.com/2009/07/migrating-from-oaw-xte xt-to-eclipse-tmf.html)
I left off in oAW at the point of implementing an error check for
duplicate definitions because I didn't want to get to much involved with
that architecture. One java example of the type of error I need to flag is
final int FOO = 1;
final int FOO = 2;
- Error: duplicate field FOO
The way I'm trying to approach this is with code similar to the code in
org.eclipse.xtext.linking.impl.DefaultLinkingService for getLinkedObjects.
I'm blocked because I really don't know how to get a reference to the
right implementation of IScopeProvider in my JavaValidator class.
I'm really hoping that since the concept of detecting duplicates is so
common, someone might be able to point me at an example. I'm pretty
familiar with parser generators, but the Ecore model and other Eclipse
conventions are still new to me.
Thanks!
John
PS
Question on DefaultLinkingService: is there a reason the
getUnconvertedLinkText method doesn't need to call the checked getScope
method? Does the IllegalStateException thrown during linking prevent
serialization? Should the other injected dependency, valueConverter, also
have a checked method to throw IllegalStateException rather than NPE if
it's not supplied?
|
|
|
|
| Re: Validation to detect duplicates [message #56226 is a reply to message #56165] |
Wed, 08 July 2009 04:34  |
| Eclipse User |
|
|
|
Hi John,
see below.
Am 08.07.2009 3:24 Uhr, schrieb John Bito:
> Hi,
>
> I've gotten my project just about to the point I was with the oAW tools.
> It definitely appears to be faster. There's certainly less memory used -
> with oAW, I had to disable the outline generation in order to stop
> filling the heap. (My blog post:
> http://jwbito.ballardview.com/2009/07/migrating-from-oaw-xte xt-to-eclipse-tmf.html)
>
Thanks for the nice words about TMF Xtext :-)
>
> I left off in oAW at the point of implementing an error check for
> duplicate definitions because I didn't want to get to much involved with
> that architecture. One java example of the type of error I need to flag is
>
> final int FOO = 1;
> final int FOO = 2;
> - Error: duplicate field FOO
>
> The way I'm trying to approach this is with code similar to the code in
> org.eclipse.xtext.linking.impl.DefaultLinkingService for
> getLinkedObjects. I'm blocked because I really don't know how to get a
> reference to the right implementation of IScopeProvider in my
> JavaValidator class.
>
I'm afraid there will be not much value in using the ScopeProvider in
your validator. A scope filters duplicate elements automatically so
there is not an easy allround solution to get any duplicate instances
and therefore no easy way to validate duplicates.
Internally we talked a lot about a meaningful default behaviour of the
validator but did not implement something yet. Please file a bugzilla.
Hopefully it will make it into 0.7.1 or more likely into 0.8.0.
> I'm really hoping that since the concept of detecting duplicates is so
> common, someone might be able to point me at an example. I'm pretty
> familiar with parser generators, but the Ecore model and other Eclipse
> conventions are still new to me.
>
Typically the code looks somewhat like:
EObject elementToCheck = ... // use a concrete class instead of EObject
String name = elementToCheck.getName();
// determine the broader context to determine the uniqueness of
// the elementToCheck, most likely you will use a concrete
// semantic object instead of EObject
EObject container = elementToCheck.eContainer();
for(EObject sibling: container.getChildren()) {
if (getName(sibling).equals(name)) {
error("message", elementToCheck, MyPackage.TYPE__NAME);
}
}
That is:
1) Compute the context that may not contain elements with equal names.
2) Iterate the content of the context.
3) Mark the validated element with an error if another one is found that
has the same name.
It is easier to use concrete classes from your semantic model instead of
EObjects and the reflective layer.
> Thanks!
> John
> PS
> Question on DefaultLinkingService: is there a reason the
> getUnconvertedLinkText method doesn't need to call the checked getScope
> method?
The checked method is actually unnecessary because we can be pretty sure
that Guice does a damn good job when assembling the objects.
> Does the IllegalStateException thrown during linking prevent
> serialization?
I'm pretty sure it does. However, it should not be thrown at all. Did
you experience any problems with uncaught exceptions?
> Should the other injected dependency, valueConverter,
> also have a checked method to throw IllegalStateException rather than
> NPE if it's not supplied?
>
No, it shouldn't. It is more likely that we remove the getScope(..)
method from the DefaultLinkingService.
Please do not forget to file the bugzilla :-)
Regards,
Sebastian
|
|
|
| Re: Validation to detect duplicates [message #56343 is a reply to message #56226] |
Wed, 08 July 2009 14:05 |
| Eclipse User |
|
|
|
Sebastian Zarnekow wrote:
> Hi John,
> see below.
Answering the question, below.
>> Question on DefaultLinkingService: is there a reason the
>> getUnconvertedLinkText method doesn't need to call the checked getScope
>> method?
> The checked method is actually unnecessary because we can be pretty sure
> that Guice does a damn good job when assembling the objects.
>> Does the IllegalStateException thrown during linking prevent
>> serialization?
> I'm pretty sure it does. However, it should not be thrown at all. Did
> you experience any problems with uncaught exceptions?
Nope. These were more code-review type questions. I'm learning about
Google Guice, too.
|
|
|
Powered by
FUDForum. Page generated in 0.03717 seconds
Home