[fpc-pascal] What's a unit?

Sven Barth pascaldragon at googlemail.com
Tue Feb 19 15:51:48 CET 2013

On 19.02.2013 15:18, Mark Morgan Lloyd wrote:
> Marco van de Voort wrote:
>> In our previous episode, Mark Morgan Lloyd said:
>>> Does a unit- rather than something it contains- have any sort of
>>> representation which is recognisably distinct from an object?
>> Maybe. But what it certain doesn't have is a runtime instance. unit is
>> mostly a compiletime concept, and the Delphi exceptions to that
>> (mostly due to
>> package system) are not implemented.
>>> I've got a situation where if a library (.dll or .so) is opened under
>>> program control it is represented by an object, with entry points
>>> expressed as methods. Alternatively, if it's statically linked then
>>> it's represented by a unit, with entry points represented by
>>> procedures and functions. That allows me to write things like
>> No, that does not exist to my best knowledge. Delphi might have ways
>> for packages, but that is also shaky (and target dependent) at best.
>> The only way is to define a record with procedure variables for the
>> static
>> case manually I guess.
> I admit that I felt fairly pleased with myself when I hit upon using
> units/objects like this, but this is definitely one of the downsides.
> OK, so is it possible to set up a constant extended record (i.e. the
> work being done entirely at compilation time) that mimics an
> instantiated object? Would
> if LibCapShim is TObject then
> ..
> be safe where LibCapShim could be either an object (possibly nil) or a
> constant extended record?

You could try to overload the "is" operator for your to be defined 
static record [AFAIK it should work]. E.g.

=== code begin ===

TLibCapShim = record
   cap_get_proc: tcap_get_proc;
   // ...

   class operator is (aLeft: TLibCapShim; aRight: TClass): Boolean; inline;

class operator TLibCapShim.Is(aLeft: TLibCapShim; aRight: TClass): Boolean;
   Result := False;

=== code end ===


More information about the fpc-pascal mailing list