Re: [fpc-devel] (ref types / circles) Re: Defer keyword
> 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;
> 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
Re: [fpc-devel] (ref types / circles) Re: Defer keyword
> 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 > 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): I use classes all the time but I thought that any assignments or passing to function args call the management operators. So if you pass a managed class to a TStringList.Add for example then AddRef will indeed by called. You're saying this isn't the case? I know the FGL classes can work with ref counted objects so why is it any different if a class type was managed and then passed into one of these types? >> 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. So this means if the property is in the private section it looks at private visibility in the parent class? Yeah that's probably right we need to do that. Some things: 1) What do read/write access even mean in the context of the default properties? The terms don't really make much sense given what the the property does. Right now the property could be read only or write only but those don't really have any affect on the hoisting process itself so it's kind of deceptive. Methods are always "read-only" but i guess you could hoist fields/properties and inherit the access level of the default property. No idea if that's helpful or just adding needless complexity. Any ideas? 2) I also think there needs to be another name for the feature than "default property" since this term is already used for array indexers and could even be used for something like traits in the future (traits would be reusing much of this code). I need to add some enum names and default_property is already used so I need to think of something else. 3) What about allowing type pointers as default properties? This should be possible and is in the spirit of the feature anyways, that is ref counting. We may need to add some additional logic to properties (just internally) so that they can be used with pointers but I'm not sure about that yet. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] (ref types / circles) Re: Defer keyword
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 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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
Ryan Joseph via fpc-devel schrieb am Sa., 8. Mai 2021, 22:33: > > > > On May 8, 2021, at 12:04 PM, Sven Barth > wrote: > > > > You need to use ChangeOwner as well, but as I wrote you need to pay > attention for which created symbol you do it at what time. > > Ok, maybe this is what I got wrong didn't use ChangeOwner. When you say > "add to" what exactly do you mean? Please post a single line code snippet > even. Thanks. > Essentially it will boil down to sym.ChangeOwner(pd.parast) However you need to keep the Owner (which is different from what you change with ChangeOwner) different as otherwise is_specialization of the procdef will not work correctly. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
