Upcoming changes to Slice

michi

Hi, this notice is to give you advance warning of an upcoming change in the semantics of Slice. For Ice versions 1.6.x and 1.7.x, the Slice parser will generate warnings for source files that are affected by these changes (but will continue to compile them); thereafter, the parser will raise hard errors. The Slice language is affected in the following two ways:

1. Definitions at global scope are no longer permitted.
   
   Currently, Slice allows you to define types, such as constants, classes, interfaces, etc. at global scope. In the future, definitions at global scope are no longer permitted. This means that the only construct that can appear at global scope is a module definition; everything else must be defined inside a module.
   
2. The name of an enclosing module can no longer be used as the name of a type.
   
   Currently, Slice allows you to define a type with a name that is the same as the name of an enclosing module. For example, the following definition is currently legal (but will no longer be legal):

   module M
   {
       module N
       {
           class M // Deprecated in version 1.6.0
           {
           };
       };
   };
   

The reason for the first restriction is that global definitions cause problems with some language mappings. For example, Python does not have a true global scope, and there are pitfalls with using classes in Java's unnamed package. Global definitions force us to use awkward and artificial mappings for some languages and prevent us from offering the "natural" mapping for certain Slice constructs. Seeing that these days, there is virtually universal agreement that global definitions are undesirable, we decided to de-support global definitions in order to improve the language mappings.

The reason for the second restriction also relates to language mappings. For example, C# and Visual Basic have a scope resolution operator, so you can specify a qualified name as M.N.M. The problem is that neither language permits anchoring of a qualified name at the global scope: name lookup always proceeds by first locating the "closest" (which is more or less the same as the "nearest enclosing") scope that has the same name as the first component of the qualified name; the remainder of the lookup is then automatically anchored at this scope. As a result, it becomes impossible to generate valid source code in such languages for certain Slice definitions that reuse the name of an enclosing module as a type name.

You could argue that the latter issue really is a language defect. However, we have no choice but to disallow such constructs; otherwise, it could become impossible to, for example, create a C# client that can talk to an already deployed C++ server, if that server uses Slice definitions that contain such repeated names.

Please take note of any warnings that are emitted by the Slice parser once we release version 1.6.0 and change the corresponding constructs. (Making the change is not difficult: simply enclose global definitions in a Slice module; at the implementation level, it is typically sufficient to add a C++ or C# using declaration or a Java import statement. For repeated names, simply rename either the type or the enclosing module that causes the clash.)

We apologize for any inconvenience this change may cause you and, as always, we welcome your feedback.

Cheers,

Michi.