Я пытаюсь показать минимальный рабочий пример, описывающий мою проблему:
Грамматика
Это xtext
грамматика, которую я создал для этого примера. (Настоящая грамматика, конечно, намного сложнее и также включает в себя продвинутый язык выражений)
grammar org.example.dsl.DSL with org.eclipse.xtext.common.Terminals
generate dsl "http://www.example.org/dsl/DSL"
Model:
elements+=Declaration*
;
QualifiedName:
ID ('.' ID)*
;
Declaration:
SimpleTypeDeclaration |
SectionDeclaration |
FieldDeclaration
;
SimpleTypeDeclaration:
"type" name=ID "=" primitive=IntegerType
;
IntegerType
{IntegerType} "int"
;
SectionDeclaration:
"section" name=ID "{"
elements+=FieldDeclaration*
"}"
;
TypeDeclaration:
SimpleTypeDeclaration |
SectionDeclaration
;
FieldDeclaration:
name=ID ":" type=[TypeDeclaration|QualifiedName] ("=" value=ValueExpression)?
;
ValueExpression:
FieldReference |
SimpleValue
;
FieldReference:
ref=[FieldDeclaration|QualifiedName]
;
SimpleValue:
{SimpleValue} "sentinel"
;
Example-Code в Example-Language
Это пример кода на языке I описано выше.
type Foo = int
section A {
foo: Foo = sentinel
}
section B {
a: A
// here I want to assign the value of a subfield of `a`
// to fubar
fubar: Foo = a.foo // crucial point
}
Глобальный индекс фрагмента кода примера
Индексатор по умолчанию фрагмента кода примера сгенерирует следующий индекс глобальной области для ссылки:
[Foo, A, A.foo, B, B.a, B.fubar]
Таким образом, с правильной областью видимости я мог бы ссылаться на все эти объекты по этим идентификаторам в моем коде с разрешением ссылки.
Но crucial point
в коде фрагмент не будет разрешен, потому что B.a.foo
соответственно a.foo
не будет в индексе.
То, что я думал и пробовал до сих пор (неполные решения)
Я подумал о настройке индекса, чтобы он дополнительно помещал B.a.foo
в индекс.
- , но это могло бы засорять индекс потенциально таким количеством ненужных URI ресурсов, что я не когда-либо захотелось ссылаться на глобальную область видимости.
- (например, я просто хочу иметь возможность ссылаться на подполя полей из раздела, из которого я на него ссылаюсь)
Создайте новое Правило в грамматике под названием Selection
=> сделайте квалифицированный выбор полей явным, предоставив настраиваемое ScopeProvider
. Но есть некоторые проблемы, с которыми я столкнулся:
- Если я все еще предоставляю возможность ссылаться на все через
QualifiedName
s, грамматика и разрешение всегда будут думать, что это ссылка на тип, как и раньше, и не буду спрашивать мой пользовательский поставщик области видимости чтобы предоставить ссылку для правила Selection
, которое перегружает оператор точки (.
) - Если я удалю механизм ссылок
[TypeDeclaration|QualifiedName]
, заменив его на [TypeDeclaration|ID]
, мне придется настроить охват для каждого базового типа и подссылки и не будет использовать мощное разрешение квалифицированных имен по умолчанию xtext.
Мой вопрос сейчас
Кто-нибудь знает о стандартное или лучшее решение проблемы, которую я описал?