Community
Participate
Working Groups
In CrossReferenceSerializer.getCrossReferenceNameFromScope String unconverted = qualifiedNameConverter.toString(desc.getName()); try { return valueConverter.toString(unconverted, ruleName); first aggregates the qualified name then converts it. Surely each segment should be converted independently. e.g. consider "a.reserved.word" in which "reserved" and "word" are both reserved and for which "^" is an escape should be serialized as "a.^reserved.^word" not as "^a.reserved.word"
Your value converter should take care of the segments. If we'd convert them per segment (e.g. in the other direction from parsed string to value), things like date: INT '/' INT '/' INT won't be possible.
I think there is a misunderstanding. This is a report against the new serializer and it seems to have nothing to do with datatype rules. If the value converter was passed the qualified name, it could handle the segments, but it isn't. For the old serializer I had to override CrossReferenceSerializer and do some rather dirty coding to outwit the value converter. The new serializer seems much better; all my overrides seem much more modular and in my derived IScopes. I have no need to override CrossReferenceSerializer, which now has restricted access, except to fix this bug. Perhaps the ^ prefix in my example is confusing. Using " and ::, The three segment logical name a::reserved::word must be serialized segment-wise back to and parsed from a::"reserved"::"word" rather than "a::reserved::word" the first is a three-segment name containing two reserved words, the second is one-segment containing punctuation. If datatype rules need different treatment then that may need a distinct code path. I see no reason why the value converter shouldn't be given the qualified name. In my case, this then allows different sets of reserved words to be used for the first segment.
(In reply to comment #2) > I think there is a misunderstanding. This is a report against the new > serializer and it seems to have nothing to do with datatype rules. > I'm afraid it's not. Your value converter is responsible for escaping the individual segments. The contract of the interface is that you split the complete string up and escape all the parts that have to be escaped. It's unlikely that we ever change that. Anyway, your example looks reasonable to me and I'll rephrase the bug's subject. Converting from / to a qualified name directly is interesting especially for cross references.
IValueConverterService.toString(Object value, String lexerRule) takes an Object argument, so no change is required to pass a QualifiedName as far as API-tooling is required. Of course user code may be surprised, but perhaps should be using String.valueOf() anyway. I'm not sure about to-QualifiedName since I'm not sure how the grammar would look and it doesn't help me with decorated qualified names such as A<B,C<D::E,F>>::G. However for from-QualifiedName with the new serializer, I'm finding it useful for A::B::C, but I'm probably going to be in trouble with decorations. Perhaps there should be an IQualifiedName that abstracts the sequence of segments allowing arbitrary representations of each segment. The value converter could then descend hierarchically though the segments and decorations.
I'll close this one as won't fix. The IValueConverter is reponsible for converting values that are contained in the model to something that can be written to text. Since the model does not have an attribute of type IQualifiedName, the value converter should not have to deal with it. Those who are concerned about a simple string concat and some indexOf operations on a char array may of course customize their own CrossReferenceSerializer. Others should not be bothered with that special case.
When I came to debugging some bad Completion Proposals, I discovered that using QualifiedName was really unhelpful since in A::B::C there are three references but only one grammar element, so proposals did not easily differ whether replacing A or B or C. After changing to use distinct grammar elements for each qualified name fragment Completion Proposals and Scope Resolution are variously better and simpler. Since QualifiedNames seem unhelpful, there is no need to make them clever.
