Duration: 35:32

919 views

3

In Xtext's grammar language syntax and structure of models are defined at a single location in a very concise way. The nesting structure and the references between objects are expressed which goes beyond plain abstract syntax trees. By just pointing to a type of an object, we describe the shape of a syntax graph. But the grammar alone has no meaning to describe the visibility rules inside of a resource or across resource boundaries. Therefore Xtext has a concept of scopes that are modeled as a chain of responsibility. Xtext comes with a good default scoping semantic that fits for most simple problems, but when the amount of models grows or your problem cannot be handled by the default you have to get in touch with the scoping API. Or as others have said it: Beyond here are dragons.

Most Xtext users know how to implement scoping rules that are applied within the same resource. After all, the API is pretty straight forward. Referencing objects located in other resources is usually more tricky. Here the so called global scope provider is doing it’s job. By default, the global scope contains every object that has a name. Again, that’s good as a starting point and will work in most of the cases, but for serious languages, it doesn't cut it. Memory consumption and performance will play a bigger role as the amount of models grows. There is no turning back: As a language engineer, you really need to understand what’s going on under the covers to define scaling implementations.

In this session we will provide a thorough explaination of the most important concepts of Xtext’s way of scoping. You will learn, that an object might have different names in different contexts and what's behind nested scopes, shadowing and filtering. We will discuss typical problems and solutions along with best practices for scoping. In the end, it's about the right compromise between implementation effort, memory consumption and performance.