> ## Content Index > Fetch the complete content index at: https://blogs.remobjects.com/llms.txt > Use this file to discover other available public pages before exploring further. # Comparing Chrome and Delphi 2005 Namespace Support - URL: https://blogs.remobjects.com/2005/03/26/comparing-chrome-and-delphi-2005-namespace-support/ - Published: 2005-03-26T16:23:33.000Z - Updated: 2018-08-22T06:17:36.000Z - Author: marc hoffman - Tags: #Import 2026-08-17 20:17 A lot of people (me included) complained about the support (or lack of support) for namespaces in Delphi for .NET when Delphi 8 was initially released. Namespaces essentially boiled down to a fancy name for "dots in the unit name" in **Delphi 8**, forcing every unit to use a unique "namespace" name and generally treating namespaces as units. **Delphi 2005** was released late last year and majorly revamped the way namespaces work, allowing more flexibility and allowing several units to populate the same namespace (a necessity when developing libraries for consumption by non-Delphi users), but the way Delphi 2005 handles namespaces is awkward, to say the least, and counter-intuitive to the extend that when i saw it described the first time, i had to read the info several times to even begin wrapping my head around it. When we set out to design **Chrome** early last year, one of our goals was to provide proper namespace support for the Pascal language, namespace support that would seamlessly integrate into the way the CLR handles namespaces and would be familiar and intuitive for user familiar with C#. Also, it was important to us that Chrome would allow the creation of libraries that could intuitively be used by both Chrome users and users of other languages such as C#, Visual Basic and, yes, Delphi for .NET. So i want to take this opportunity to compare namespace support in Delphi 2005 and Chrome, and point out the design decisions we made for Chrome in order to make its namespace support as intuitive as possible. This comparison breaks down into 6 major points: **(1)** In Chrome, what you see is what you get. If you type "*namespace* *x.y.z*", that’s your namespace. In Delphi, namespace names and unit names are separate things. If you have units "*x.y.z*" and "*x.y.a*" (which incidentally have to be named "*x.y.z.pas*" and "x.y.a.pas"), the actual namespace will be "*x.y*". To make things more confusing, if you now want to use a type from these, then in Delphi you still have to specify the **unit name** (ie "*uses x.y.z, x.y.a;*"), while from all other languages you will use the **namespace name** (ie "*using* *x.y;*" in C#, "uses x.y;" in Chrome, etc). If you’re a 3rd party developer deploying your library to other developers, you’ll have to provide separate docs with separate class names for Delphi vs. other users. Confused yet? **(2)** While inside Delphi (ie not consuming Delphi code form other languages), you lose pretty much all the benefits of namespaces; you have to use the full unit names, as mentioned above. Also, you cannot have circular references between the units that "make up the namespace". By contrast, in Chrome you can use the same namespace name in as many file headers as you’d like and – whether in the same project or when consuming the .dll from another Chrome/C#/whatever project – these files are treated as one big namespace; all the classes can see and reference each other; circular references are not an issue. **(3)** Even between different namespaces, circular uses clauses are not an issue. So you can have "*uses b;*" in one or more files of "*namespace* *a;*" and "*uses a;*" in one or more files of "*namespace* *b;*" without any worries. This finally allows to conveniently spread class hierarchies to several files even of the classes need to reference each other – a common problem in Delphi – and classic Object Pascal in general – that could only be worked around by placing all classes in a single file. **(4)** Regardless of the namespace that’s set for a given file using the "*namespace*" keyword, you can always declare classes into any other arbitrary namespace by using the full name in the class declaration and method implementations, allowing you to have classes from a single file go into separate namespaces (a rare requirement, granted, but it does come in handy at times). **(5)** To access a type in Delphi, you MUST have its namespace in the uses clause – even if you use the full class name. so "*x := System.Some.Obscure.MyObject.Create(…);*" will not work in Delphi, unless you also have "*System.Some.Obscure*" listed in the uses clause (which of course makes the repetition of "System.Some.Obscure" in the Create statement redundant). Another example of the unit-centricity of Delphi’s namespaces. In Chrome, you don’t need this; all available types (i.e. types from all referenced assemblies and all types defined in the current project) are available at ANY place where you could use a type name, via their full name – regardless of whether their namespace is in the uses clause or not; you only need to "use" the namespace if you want to refer to the types via the short name (ie as "*x := new MyObject(…);*" without the namespace prefix. **(6)** Finally, as a convenience feature for using large nested namespace hierarchies, Chrome allows the use of the \* wildcard in it’s uses clause, to use an entire namespace hierarchy. As a result, "*uses System.Xml.*;\*" for example gives access to the entire set of Xml classes – including those located in sub-namespaces such as *System.Xml.XPath*. I hope the above gave you a quick overview of how namespace support works in Chrome, and what benefits it offers over Delphi 2005’s awkward namespace system. If you have any questions or suggestions, please let me know. Also, be sure to check out our March Preview of the free Chrome command line compiler, to see the Chrome language in action, now!