Hi,
On 2013/02/19, at 22:53, Marco van de Voort mar...@stack.nl 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
Does a unit- rather than something it contains- have any sort of
representation which is recognisably distinct from an object?
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.
On Tue, Feb 19, 2013 at 3:31 PM, Mark Morgan Lloyd
markmll.fpc-pas...@telemetry.co.uk wrote:
Does a unit- rather than something it contains- have any sort of
representation which is recognisably distinct from an object?
I've got a situation where if a library (.dll or .so) is opened under
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
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
ik wrote:
On Tue, Feb 19, 2013 at 3:31 PM, Mark Morgan Lloyd
markmll.fpc-pas...@telemetry.co.uk wrote:
Does a unit- rather than something it contains- have any sort of
representation which is recognisably distinct from an object?
I've got a situation where if a library (.dll or .so) is opened
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
Sven Barth wrote:
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
On 19.02.2013 17:49, Mark Morgan Lloyd wrote:
Sven Barth wrote:
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
Sven Barth wrote:
Thanks Sven, looks interesting and I'll play with it presently. Can an
extended record's fields/methods be set up at compilation time, or do
they need to be done by code?
The example I've given was for the case that you load the functions
dynamically and use the procvars
On 19.02.2013 18:08, Mark Morgan Lloyd wrote:
Sven Barth wrote:
Thanks Sven, looks interesting and I'll play with it presently. Can an
extended record's fields/methods be set up at compilation time, or do
they need to be done by code?
The example I've given was for the case that you load
Sven Barth wrote:
On 19.02.2013 18:08, Mark Morgan Lloyd wrote:
Sven Barth wrote:
Thanks Sven, looks interesting and I'll play with it presently. Can an
extended record's fields/methods be set up at compilation time, or do
they need to be done by code?
The example I've given was for the
12 matches
Mail list logo
