This is the second article in the series (I, III, IV, V, VI) of articles designed with one goal in mind: to provide a quick and dirty introduction to the world of .Net programming with Delphi. If you are looking for "what you need to know about Delphi 8 for .Net" - you're at the right place!
Here's what you need to know about the new Delphi language features in Delphi for .Net (versions 8+). Find out about unit namespaces and the new class visibility and access specifiers.
Back in the first article, you've been introduced to the new world of Delphi development: Delphi 8 for .Net. The idea of the first article was to explain what Delphi 8 is, and what does it offer to a Win32 Delphi developer.
Starting with this article you'll learn exactly what you need to know about the new Delphi language features in Delphi 8 for .Net - not more, not less.
Delphi 8 for .Net: the language
Ok, so Delphi 8 is pure .Net - whatever that means :)In order to fully support .Net - or better to say: in order to be a first .Net citizen, Borland needed to introduce significant changes to the Delphi language. Beside the language enhancements, Delphi for .Net compiler has also been adapted for the .Net framework. What Delphi 8 brings is a a new code generator, a new linker, enhanced syntax, and a new runtime library.
Let's go step by step.
Units vs. Namespaces
First a good news: units are still the basic container of types, and all your code. In .Net, namespaces provide a logical organizational system, when examined from the Delphi 8 persective, a namespace is a container of Delphi units. In general, namespaces disambiguate types with the same name - they allow the FCL hierarchy to be extended by third party assemblies without having to wary about conflicting symbol names. The .NET Framework types use a dot syntax naming scheme that connotes a hierarchy.In Delphi for .Net, the namespace to which a unit belongs is defined in the unit header; a project file (program, library, or package) implicitly introduces its own namespace, called the project default namespace.
For example, in unit ADP.Web.MyUnit, the name of the unit is ADP.Web.MyUnit, and ADP.Web is the namespace. The source file name for this unit is ADP.Web.MyUnit.pas, and the compiled output file name is ADP.Web.MyUnit.dcuil. In this example, the unit MyUnit explicitly declares itself to be a member of the ADP.Web namespace.
By default, the program (library, package) keyword declares the namespace for the entire project. A unit that omits an explicit namespace is called a generic unit. Generic units automatically become members of the project namespace. Thus, if a program is named "MyProgram", and you add a new unit to the project, name the unit "MyUnit" - MyUnit automatically resides in the "MyProgram" namespace.
For example, when you create a new Windows Forms application, in the source code for the Form object, you'll find the uses clause that looks like:
~~~~~~~~~~~~~~~~~~~~~~~~~
uses
System.Drawing, System.Collections, System.ComponentModel,
System.Windows.Forms, System.Data;
~~~~~~~~~~~~~~~~~~~~~~~~~
The System.Windows.Forms is the .Net's namespace that FCL based contains classes for creating Windows-based applications.
That's enough on units and namespaces for the moment, we'll explore more this topic much more in the future (with some examples).
We now move to a discussion on class members visibility...