Summary: Namespaces (Goran's proposal)
Last updated at 8:53 am UTC on 25 February 2005
What problem is being addressed
The problem of maintaining names of globals (classes) in a global world and handling naming conflicts, not just hiding them.
How it solves the problem
The problem is solved by embracing the use of prefixes as a simple namespace solution. A prefix is a namespace today, we just don't call it that.
The solution introduces a ::-separator between the prefix and the class name thus making the prefix detectable. This means we can see what classes have prefixes and we can see what the prefix is. The model is just like with prefixes now:
- Each prefix is a namespace
- The namespace has a simple name (the prefix) and they are all on the same level (no hierarchy)
- Just as now, classes without prefixes are just globals. So you don't have to put classes in a namespace.
- No imports whatsoever, and compile time binding just like now. But this is obvious since this is just "Prefixes Improved".
The solution is deadly simple and totally backwards compatible, it only involves a few small modifications to Scanner/Parser/Encoder to be able to handle $: in global names. The rest is "tool support" which is optional and of course makes it all very much more worthwhile - like being able to only type and read shortnames (99% of the time) and getting nice menus popping up helping you choose in case of duplicate shortnames in the image etc.
The effect of the technical solution and the combined tool support is what I have called "optimistic" namespaces. By this I mean that if there are duplicate names in different namespaces we will notice it (you will be asked to choose which one you mean) which in turn means we will all work to minimize those conflicts and naturally tend to work together and merging classes that try to solve the same problem. It also keeps the "mental" namespace clean, no matter which technical solution is chosen we humans only have one "namespace" and that is our skull. Having to distinguish between 4 different "Button" or "Socket" or "Manager" is not good. So even between namespaces we should minimize clashes, and that will only happen if we notice them (which we don't in a pessimistic solution).
Useful links
The latest little article describing it and the SM entry.
Also posts on the subject describing it:
For coherence I think the author should write the sections above this line.
People can add what they want to these later sections, and can suggest that the author change the rest.
What's cool about it
What's not
Commentary
Back to New Modules
