> On May 10, 2021, at 3:18 PM, Ryan Joseph wrote:
>
> Lets focus on the record approach for now then. I don't think I know enough
> to understand where are the pitfalls are.
This was another thing I wanted off my mind since a couple years ago already so
I got a pretty good start of an
Am 10.05.2021 um 23:18 schrieb Ryan Joseph via fpc-devel:
On May 10, 2021, at 3:05 PM, Sven Barth via fpc-devel
wrote:
Why should they? You pass the reference to a non-reference counted
parameter/field/variable, the reference count is increased and then what? It
sits there for the
> On May 10, 2021, at 3:05 PM, Sven Barth via fpc-devel
> wrote:
>
> Why should they? You pass the reference to a non-reference counted
> parameter/field/variable, the reference count is increased and then what? It
> sits there for the remaining life time of the program, because nothing
>
Am 09.05.2021 um 17:14 schrieb Ryan Joseph via fpc-devel:
On May 9, 2021, at 3:40 AM, Sven Barth wrote:
=== code begin ===
{$mode objfpc}
type
TTest = class
protected
procedure DoSomething;
end;
TTestSub = class refcounted(TTest)
public
procedure Test;
end;
Am 09.05.2021 um 16:58 schrieb Ryan Joseph via fpc-devel:
On May 9, 2021, at 3:40 AM, Sven Barth wrote:
It seems that you don't work much with classes then. If one disallows the
assignment of a reference counted class to a non-reference counted one then you
can't use e.g.
Over the weekend I fixed up my old default property code to work with records
only which implement classes (which reduced lots of the complexity). It's
actually a pretty clean and small implementation so I put a patch you can look
at and try. It's not decided upon but this is a place to start
> On May 9, 2021, at 3:40 AM, Sven Barth wrote:
>
> === code begin ===
>
> {$mode objfpc}
>
> type
> TTest = class
> protected
> procedure DoSomething;
> end;
>
> TTestSub = class refcounted(TTest)
> public
> procedure Test;
> end;
>
> procedure TTest.DoSomething;
>
> On May 9, 2021, at 3:40 AM, Sven Barth wrote:
>
> It seems that you don't work much with classes then. If one disallows the
> assignment of a reference counted class to a non-reference counted one then
> you can't use e.g. TStringList.Objects. There is also the problem of method
>
Am 08.05.2021 um 19:38 schrieb Ryan Joseph via fpc-devel:
On May 8, 2021, at 11:18 AM, Sven Barth wrote:
It's not about reference counted classes vs. managed records, but about whether
it's *per type* or *per variable*, the implementation details are completely
irrelevant for now.
So the
> On May 8, 2021, at 11:18 AM, Sven Barth wrote:
>
> It's not about reference counted classes vs. managed records, but about
> whether it's *per type* or *per variable*, the implementation details are
> completely irrelevant for now.
So the biggest concern you see if that classes are easier
Am 08.05.2021 um 18:23 schrieb Ryan Joseph via fpc-devel:
On May 8, 2021, at 7:59 AM, Sven Barth via fpc-devel
wrote:
It has the exact same problems that my branch had (especially the interaction
of reference counted instances with non-reference counted ones).
Using a
> On May 8, 2021, at 7:59 AM, Sven Barth via fpc-devel
> wrote:
>
> It has the exact same problems that my branch had (especially the interaction
> of reference counted instances with non-reference counted ones).
>
> Using a variable/parameter/field based approach (like the idea with
Am 07.05.2021 um 23:16 schrieb Ryan Joseph via fpc-devel:
On May 7, 2021, at 2:52 PM, Sven Barth wrote:
As said the main problem of reference counting on object instances, especially
if enabled by default like the Delphi NextGen compiler did, will lead to
problems in *existing* code and
> On May 7, 2021, at 2:52 PM, Sven Barth wrote:
>
> As said the main problem of reference counting on object instances,
> especially if enabled by default like the Delphi NextGen compiler did, will
> lead to problems in *existing* code and thus is a no-go.
>
What did you think about me
Ryan Joseph via fpc-devel schrieb am Fr.,
7. Mai 2021, 05:58:
>
>
> > On May 6, 2021, at 7:14 PM, Ryan Joseph wrote:
> >
> > This can be detected at compile and at least give a warning. "a" is a
> member of TR and the element type of "a" is TR, then we're assigning TR to
> said array. It's that
> On May 6, 2021, at 7:14 PM, Ryan Joseph wrote:
>
> This can be detected at compile and at least give a warning. "a" is a member
> of TR and the element type of "a" is TR, then we're assigning TR to said
> array. It's that simple I think.
It also occurs to me that record management
> On May 6, 2021, at 5:41 PM, Martin Frb via fpc-devel
> wrote:
>
> You can already cause ref circles, no classes needed.
>
> type
> TR = record
> a: array of TR;
> end;
>
> var
> x: TR;
> begin
> SetLength(x.a,99);
> x.a[0] := x;
> end.
This can be detected at compile and at
Hi Martin,
07.05.2021 2:41, Martin Frb via fpc-devel:
On 07/05/2021 01:36, Nikolai Zhubr via fpc-devel wrote:
Indeed. However, unfortunately classes are substantially different in
that they can cause reference circles,
You can already cause ref circles, no classes needed.
Yes, records and
On 07/05/2021 01:36, Nikolai Zhubr via fpc-devel wrote:
Indeed. However, unfortunately classes are substantially different in
that they can cause reference circles,
You can already cause ref circles, no classes needed.
type
TR = record
a: array of TR;
end;
var
x: TR;
begin
19 matches
Mail list logo
