[fpc-devel] (ref types / circles) Re: Defer keyword

Sven Barth pascaldragon at googlemail.com
Sun May 9 11:40:33 CEST 2021


Am 08.05.2021 um 19:38 schrieb Ryan Joseph via fpc-devel:
>
>> On May 8, 2021, at 11:18 AM, Sven Barth <pascaldragon at googlemail.com> 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 to assign to non-reference counted classes? The only difference between classes and records in this regard is that records give errors unless you assign directly to the same record type, where classes can be assigned to super-classes which may not be managed.
>
> As you say there would need to be at least a warning if you cast a managed class to another class type or make it forbidden completely. I don't see that as a deal breaker personally but you seem to feel pretty strongly about it.

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 pointers, which essentially only have a Pointer as 
Self data. Also a reference might escape in a parent class (for this 
example I'll use the syntax I used in my branch):

=== 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 ===

Obviously these problems won't be solved with the alternative approach 
either, but likely one can make clear more easily that the use case is 
for local instances.

> Anyways I wrote up a little wiki with some potential implementation notes about a default property (which overlaps on the "defaults implements" as traits stuff). Important points are restricting what types can be default properties (classes and maybe/probably typed pointers) and limiting hoisting to subscripting, so it's kind of like the -> operator overload in C++.
>
> https://github.com/genericptr/freepascal/wiki/Default-property
It shouldn't hoist only public members, it should hoist according to the 
visibility rules (thus the hoisting depends on the callsite), otherwise 
it won't behave like Pascal classes do and thus we can forget it right away.

Regards,
Sven


More information about the fpc-devel mailing list