Assemblies and Delphi

The Delphi for .NET compiler treats CLR assemblies like Delphi packages. The compiler supports direct symbol importing from metadata. Header file translations are no longer needed. Symbols can be imported from any Common Language Specification (CLS) compliant .NET assembly, produced by any .NET language tool. Conceptually, every .NET assembly contains the equivalent of a DCP (which is a collection of DCUs) and a BPL, all lumped into one file.

The compiler supports the -lu<name> switch to specify which assemblies to link with or allow access to. These assemblies do not have to be Delphi assemblies. Any CLR assembly can be used directly with Delphi for .NET, with no translations or conversions. Just as you use -lu for Delphi packages, you can use -lu for any CLR assembly.

The Delphi package syntax produces assemblies. Furthermore, the package syntax will still provide the option of linking referred code directly into your exe, or making it an external reference.

The .NET assemblies don''''t give you the option of internal or external linking of code. You can support internal or external linking by distributing the DCUs as well as DCPs + BPLs. You cannot link code compiled in a package into an exe. You have to have a DCU (or source) to do that. The DCCIL compiler behaves the same as the DCC32 compiler.

You should also know that Delphi for .NET will preserve the case for the namespaces you create. C#''''s recognition of namespaces is case sensitive, so if you use a Delphi for .NET assembly with C#, you will need to match the original case of the namespace you created. Delphi''''s recognition of namespaces is not case sensitive, so if you don''''t keep this behavioral difference of the languages in mind, you might run into problems later.

Delphi Language Enhancements

I''''m sure you were all looking closely at the code above, even though I told you it would change. Some of the enhancements to Delphi are obvious by looking at the source code, but not all of them are demonstrated in the above code sample.

Let''''s look at a partial list of Delphi language enhancements.

Unit namespaces

By examining the above source code, one obvious change should be the support for unit namespaces. Namespaces allow you to access units with fully qualified identifiers, such as:

uses Borland.Delphi.SysUtils;

The Delphi unit defines its own namespace with dotted names in the unit identifiers and file names. (The file name and unit name still match, with the ".pas" omitted from the unit name.)

Project namespace

You can configure project-specific namespace resolution. Project namespaces are a great way to eliminate uses clause IFDEFs. The project namespace will determine how the unit name references are fully resolved.

Project namespace search path

There will also be support for a project namespace search path, which supports searching the namespace path for unqualified unit names on the search path. Consider this hypothetical example:

uses Forms;

This reference would resolve to Borland.VCL.Forms for a VCL project, and Borland.CLX.Forms for a CLX project. Clearly, this will make code for cross-platform development (such as .NET, Win32, and Linux) much easier to write and maintain.

Default project namespace

You can also create units that can be compiled into multiple project namespaces. For example,

unit MyControl;

would compile to Borland.VCL.MyControl.dcuil for a VCL project, and Borland.CLX.MyControl.dcuil for a CLX project.

Qualified identifiers

Reserved words or keywords are allowed after the first identifier. For example, in the following code:

var
  foo : System.Label;

Qualified identifiers can appear in type expressions, but not in identifier declarations. System.Label would be allowed as a valid type expression although label is a reserved word in Delphi. Future compiler plans for the extended identifier syntax include allowing the use of Unicode/UTF8 identifiers after the first "standard" identifier.

The Common Language Specification includes this extended identifier syntax. The dccil compiler will provide access to all CLS compliant symbols in CLR assemblies.

Nested types

Consider the following code:

type
TMyClass = class
  Fdata: Integer;
  const foo = 12;
  type TNestedClass = class
    procedure Hello;
  end;
  procedure Green;
end;
...
var
  MyClass : TMyClass;
  MyNest: TMyClass.TNestedClass;
...
begin
  MyClass.Fdata := 15;
  MyNest.TNestedClass := TMyClass.TNestedClass.Create;
  MyNest.Hello;
  MyClass.Green;
end;

The TNestedClass type is nested inside of the TMyClass type, but doesn''''t affect instances of TMyClass because data fields defined in TMyClass.TNestedClass do not occupy space in instances of TMyClass. Nested types are an extension of the namespace idea; logical containment by naming convention, with no physical manifestation.

In the above example, MyNest is not freed because it will be garbage-collected by the .NET runtime.

Custom Attributes

Delphi for .NET will support standard attributes, such as Conditional, Obsolete, Serializable, and web methods. You will also be able to create custom attributes, such as those displayed here:

type
  [ FooAttribute(''''Hello'''', 23) ]
  TMyClass = class
    [ SpecialDataAttribute ]
    Fdata: Integer;
    [ WebMethod, DebuggerStepThrough ]
    function SampleCount: Byte;
  end;

Declaring custom attributes

Delphi allows you to create custom attributes you can use for any of your .NET application source code, such as the TQuantumAttribute declared here:

type
  TQuantumAttribute = class(TCustomAttribute)
    constructor Create;
    constructor Create(Name: String);
    property Name: String ...;
    property Spin: Double ...;
    property Color: TQuarkColor ...;
  end;

A poster child for custom attributes might be the DLLImportAttribute. The Borland.Win32.Windows unit will be using that attribute for indicating the requirement for Windows run-time DLLs. CLR supports more options for referencing external DLL functions than regular old PE DLL Imports. Rather than add more special syntax to the language to cover those additional CLR-specific options, the additional info can be carried in an attribute. The compiler can remain blissfully ignorant of the payload for all but a handful of custom attributes.

Class (static) data

You can have class variables in your objects. This allows you to do things like perform instance counts or track information that is class specific rather than instance specific in your objects.

type
TMyClass = class
  class Fdata: Integer;
  class property Foo: String ...;
  class procedure One;
  class static procedure Two;
end;

Class properties

Class properties work like class fields. The getters and setters must be class methods or class fields.

Class static methods

Class static methods work the same as traditional Delphi class methods, except that there is no "self" parameter available in the method body. This is a CLR requirement because some languages do not support the hybrid behaviors Delphi has, where you can have routines that are not part of an object. Traditional Delphi class methods (which do have a "Self" in the body of the method) will also be supported.

Value types

Types can be "boxed" into object wrappers. These value types are not reference types. They are the actual instance of the type. Value semantics are supported for assignment and copying data. Record types are an example of value types in Delphi. Records can inherit from other records, and records can contain non-virtual methods, properties, and nested types.

When value types are boxed, a fresh copy of the value is made and a distinct object reference is returned. This distinct object reference is a reference to data that is completely independent of the und

上一页  [1] [2] [3] [4]  下一页

打印本文 关闭窗口
Delphi for .Net 编译器预览 - by John Kaster
作者：武汉SEO闵涛  文章来源：敏韬网  点击数4207  更新时间：2009/4/23 18:39:15  文章录入：mintao  责任编辑：mintao
sely, but also because compatibility type mappings will be provided. The following table shows some classes and technology areas that map easily between Delphi and the .NET runtime.	Delphi for .NET	.NET CLR
打印本文 关闭窗口