User loginNavigation |
Alternatives to ADL?I'd like to explore the topic of argument-dependent lookup (a.k.a. Koenig lookup), and in particular I'd be interested to find out what people think is the "state of the art" when it comes to resolving unqualified identifiers. It's my opinion that one of the primary motivations for ADL is to support operator overloading. The function of ADL is to resolve unqualified names, and operators are essentially functions with unusual unqualified names. For functions that have regular names and which are not operators, it's often not a huge burden to explicitly qualify the name, or to manually import it into the current scope. But for operators this destroys their brevity and convenience. There are many supporters and detractors of ADL and I won't try and repeat all the arguments here. The common theme is that ADL leads to surprise. However, one limitation that interests me is that the methods which operate on the arguments must live in the same namespace with the definitions of those types. This is not such a hardship in languages like C++ where there's no enforced relationship between the namespace hierarchy and the organization of modules and source files, where any header file can append to any namespace. But for many modern languages that's not the case, the package hierarchy is much more rigid (often with good reason.) I can imagine scenarios where the co-location of operations and types within the same module would be overly restrictive - you might want to extend the set of operations for some set of types (think of a vector math library) without re-defining those types. So what are the alternatives? I can think of several. The simplest one is to require that unqualified name definitions be explicitly imported into the module's namespace. This has the benefit of being easy to understand, but I'm not sure how well this scales to large programs - you risk polluting your namespace with a lot of symbols. Another solution is to allow a more limited kind of namespace extension. Some languages have syntax that allows adding methods and definitions to classes only (not namespaces or packages), usually with keywords like "extends" or "extension". This requires that the unqualified names be defined within the class, rather than outside it, which usually implies that the enclosing class "owns" the definitions or at least has special status. In a single-dispatch world, of course, these definitions are methods, which means you run into the "binary operator" problem - who owns the definitions of A+B, is it A or B? A third approach is to completely give up on static scoping and use dynamic dispatch - i.e. if there's a definition of A+B anywhere in the program, it will be used, even if it's not visible at the call site. However, while dynamic multi-argument dispatch is a valuable technique, it is not without it's set of costs. One that I'm particularly interested in is the "plugin problem", which is that if you are Adobe Photoshop and you load some filter plugin that happens to contain a new definition of the plus operator, does it suddenly change the behavior of your whole program? Or on the opposite extreme, does the plugin contain its own sandboxed versions of all the operators and type definitions? Neither seems desirable to me - the plugin needs at minimum to implement some interface defined outside of the plugin, but its effects need to be limited and predictable. The benefit of static scoping is that the conceptual search space for unqualified name lookups is smaller and more predictable, and thus easier to reason about - a programmer need only look at the set of imported symbols and their transitive dependencies, instead of having to search a universe of code. Anyway, I'm interested to know if there's anything out there that's clearly better than the techniques that I've described. By Talin at 2014-05-01 02:44 | LtU Forum | previous forum topic | next forum topic | other blogs | 3982 reads
|
Browse archives
Active forum topics |
Recent comments
22 weeks 6 days ago
22 weeks 6 days ago
22 weeks 6 days ago
45 weeks 16 hours ago
49 weeks 2 days ago
50 weeks 6 days ago
50 weeks 6 days ago
1 year 1 week ago
1 year 6 weeks ago
1 year 6 weeks ago