<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Comments for Namespaces in Delphi 2005 by Marc Rohloff</title>
<link rel="alternate" type="text/plain" href="http://dn.codegear.com/article/32765" title="Namespaces in Delphi 2005 by Marc Rohloff" />
<link rel="self" type="application/atom+xml" href="http://dn.codegear.com/article/32765/feed" title="Comments for Namespaces in Delphi 2005 by Marc Rohloff" />
<id>http://dn.codegear.com/article/32765</id>
<updated>2008-10-07T17:22:25-07:00</updated>
<entry>
<title>Namespaces in Delphi 2005 by Marc Rohloff</title>
<author>
<name>Stephan Petersen</name>
<uri>http://threads.codegear.com/threads/threads.exe/userall?commentid=38539</uri>
</author>
<id>http://threads.codegear.com/threads/threads.exe/view?commentid=38539</id>
<updated>2005-07-11T03:14:37-07:00</updated>
<published>2005-07-11T03:14:37-07:00</published>
<summary>Namespaces in Delphi 2005 by Marc Rohloff</summary>
<content>The introduction states very prominently that this topic is not relevant for Win32 programmers, and that &quot;you normally do not even have to be concerned about namespace support in Delphi at all&quot;.I'm currently finding out the hard way that this doesn't seem to be the case. Win32 Code (in my case, VCL component libs) is affected in terms of the help written for the components and their members. If your unit names are generic, which most pre-D2005 units likely are, good luck in getting your context sensitive help to work! F1 is just not working for your components, nowhere.Without dealing with the issue of namespaces, Win32 component programmers are very likely producing online help that leaves their users in the dark, even with the help of professional tools like Doc-O-Matic.Another critical case where Borland failed to provide enough information for professional developers.</content>
</entry>
<entry>
<title>Namespaces in Delphi 2005 by Marc Rohloff</title>
<author>
<name>Pierre Axelsson</name>
<uri>http://threads.codegear.com/threads/threads.exe/userall?commentid=38077</uri>
</author>
<id>http://threads.codegear.com/threads/threads.exe/view?commentid=38077</id>
<updated>2005-01-16T07:44:40-08:00</updated>
<published>2005-01-16T07:44:40-08:00</published>
<summary>Namespaces in Delphi 2005 by Marc Rohloff</summary>
<content>&quot;Always use Packages not Libraries to create shareable assemblies.&quot;It sounds very good, but not practically possible because &quot;Link Units&quot; doesn't work when building .net packages. That means one would have to distribute dependent assemblies. See QC #9887.</content>
</entry>
<entry>
<title>Namespaces in Delphi 2005 by Marc Rohloff</title>
<author>
<name>Peter Gummer</name>
<uri>http://threads.codegear.com/threads/threads.exe/userall?commentid=37927</uri>
</author>
<id>http://threads.codegear.com/threads/threads.exe/view?commentid=37927</id>
<updated>2004-12-09T16:07:42-08:00</updated>
<published>2004-12-09T16:07:42-08:00</published>
<summary>Namespaces in Delphi 2005 by Marc Rohloff</summary>
<content>Great article Marc.There's one inaccuracy. The executive summary says, &quot;Delphi will always refer to types by their unit name&quot;. This isn't so in the following situation:1. You have a package with a default namespace. The default namespace is emitted into the assembly.2. You have another Delphi project that references the package.Rather than referring to types in the package by their unit name, the Delphi code in this project has to refer to them by the unit name prefixed with the default namespace. This includes uses clauses in the project source file.Alternatively, the project has to have the same default namespace as the package ... but that's probably not what you would want.Unfortunately, failure to use either of these solutions does not produce compiler errors. Instead, you get a cryptic TypeLoadException as the program starts. The only real clue that Delphi gives of how to fix this problem is through code insight.</content>
</entry>
<entry>
<title>re: Namespaces in Delphi 2005 by Marc Rohloff</title>
<author>
<name>Marcel Bestebroer</name>
<uri>http://threads.codegear.com/threads/threads.exe/userall?commentid=37916</uri>
</author>
<id>http://threads.codegear.com/threads/threads.exe/view?commentid=37916</id>
<updated>2004-12-05T04:48:00-08:00</updated>
<published>2004-12-05T04:48:00-08:00</published>
<summary>re: Namespaces in Delphi 2005 by Marc Rohloff</summary>
<content>I wrote earlier: &quot;I wonder if it wouldn't have been better if Delphi accepted use A.B and automatically (implicitly) use all units in that namespace.&quot;As it turns out, you can do that just fine. Just use the magic of &quot;Unit aliases&quot;. So, you can specify a unit alias like 'A.B=A.B.C, A.B.D'. If you now add a 'uses A.B' in your project, you automatically get both units.</content>
</entry>
<entry>
<title>Namespaces in Delphi 2005 by Marc Rohloff</title>
<author>
<name>Marcel Bestebroer</name>
<uri>http://threads.codegear.com/threads/threads.exe/userall?commentid=37914</uri>
</author>
<id>http://threads.codegear.com/threads/threads.exe/view?commentid=37914</id>
<updated>2004-12-04T01:23:15-08:00</updated>
<published>2004-12-04T01:23:15-08:00</published>
<summary>Namespaces in Delphi 2005 by Marc Rohloff</summary>
<content>While it is certainly the very nice solution, I have a problem with the fact that you *have* to use the full unit name when using an assembly written in Delphi. The problem lies in documentation. You are now forced, when writing a class library in Delphi that is to be used with other .NET languages, to specify that type X is in namespace A.B, but Delphi users will need to use unit A.B.C. That just looks silly and C# and/or VB.NET users will make fun of us. I wonder if it wouldn't have been better if Delphi accepted use A.B and automatically (implicitly) use all units in that namespace. At least then you could be consistent in whatever language you use the Delphi written assembly.</content>
</entry>
</feed>
