|
|
| Re: Validation to detect duplicates [message #56226 is a reply to message #56165] |
Wed, 08 July 2009 08:34   |
 Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
|
Powered by
FUDForum. Page generated in 0.03088 seconds
] 
Search
Help
Register
Login
Home
