> On May 9, 2021, at 3:40 AM, Sven Barth <pascaldra...@googlemail.com> wrote:
>
> === code begin ===
>
> {$mode objfpc}
>
> type
> TTest = class
> protected
> procedure DoSomething;
> end;
>
> TTestSub = class refcounted(TTest)
> public
> procedure Test;
> end;
>
> procedure TTest.DoSomething;
> begin
> // maybe this functions stores the reference
> SomeFuncThatTakesAObject(Self);
> end;
>
> procedure TTest.Test;
> begin
> DoSomething;
> end;
>
> === code end ===
I see, the reference counting is broken because you move up into a non-ref
counted class. Yeah that's something programers simply should not do or be
prevented from doing. I don't see this particular case being a problem however
because your ref counted object is going to be in the base of a hierarchy,
probably enforced even. The only reason for opt-in ARC is so we don't pollute
TObject but it still doesn't mean that you should be adding this in the middle
of class trees.
Here is the bigger problem:
var
list: TObjectList;
procedure HandleObject(obj: TObject);
begin
// the list now stores the class but it's lost ref-counting because it was
cast to TObject
list.Add(obj);
end;
var
obj: TTestSub;
begin
HandleObject(obj);
end;
or
var
obj: TObject;
begin
// we lost ref counting now!
obj := TTestSub.Create;
HandleObject(obj);
end;
Once you cast away from your managed class type things fall apart. Records aid
this by not allowing casting but you could enforce some kinds of checks for
managed classes if you wanted to. Doesn't seem like a deal breaker to me if you
add new type rules for passing/assigning.
Regards,
Ryan Joseph
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
