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;
end;
class operator TLibCapShim.Is(aLeft: TLibCapShim; aRight: TClass): Boolean;
begin
Result := False;
end;
=== code end ===
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
