[fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Sven Barth schrieb:
> Am 27.10.2014 21:00, schrieb Hans-Peter Diettrich:
>> Sven Barth schrieb:
>>> Am 27.10.2014 17:20 schrieb "Hans-Peter Diettrich" 
>>> <DrDiettrich1 at aol.com <mailto:DrDiettrich1 at aol.com>>:
>>
>>>  > Something like ShortString and AnsiString?
>>>
>>> With the difference that Short- and AnsiString are assignable to 
>>> eachother while Jonas does not want that for reference counted and 
>>> ordinary classes.
>>
>> Where would this matter? When TObject and TManagedObject are different 
>> (base) types, a direct assignment of references is impossible.
> Take unit Typinfo for example where quite some methods take a TObject 
> instance.

The TypInfo methods can determine the exact type of their arguments, and 
act inside accordingly.

> Or all those classes (TStrings, TObjectList, TComponent, etc.) 
> that somewhere take a TObject as parameter.

IMO containers play a different role in managed and unmanaged 
environments. E.g. an TObjectList.OwnsObjects property is useless with 
managed objects, and the circular owner/child and parent/child 
references in several persistent classes deserve special attention and 
handling, when used with managed objects. Similar considerations apply 
to strings - should TStrings contain AnsiStrings or UnicodeStrings, 
where despite their assignment compatibility the implicit conversions 
between both can consume much runtime.

For such reasons I'd prefer a separate environment (RTL...) for only 
managed and unmanaged objects, just like for AnsiString and 
UnicodeString. But in combination such options would end up in many 
different library versions, so that I do not really suggest such an 
implementation. My dream are distinct FPC/Lazarus versions, designed for 
compatibility with D7, D2009, Unicode, Mobile and whatever versions may 
show up in the future. Then it should be possible to freeze the old 
versions with all bugs fixed, and new features will be added only to 
newer versions; this would eliminate all beforementioned problems, 
resulting from mixing features of different Delphi versions.

IMO Delphi versions don't offer backwards compatibility for good 
reasons, instead a purchased licencse allows to *also* use all older 
versions, down to D7. What I'm missing here are bugfixes, because the 
development of older versions is almost stopped as soon as a new version 
is distributed. Known bugs are mostly fixed only in newer versions, 
which introduce new bugs and features at the same time - good for sales 
but bad for the customers. Since FPC/Lazarus are open source, user 
groups may offer continued support for their preferred version(s), by 
backporting bugfixes into these versions.


>>> What do you mean with "virtual counting methods"?
>>
>> Overriding these methods can enable/disable refcounting for a class, 
>> and all classes derived from it. The default then can be to do nothing 
>> (no counting).
> But then it's the same reference counting as the COM one, because 
> without the COM reference counting those virtual methods would not be 
> called.

So you prefer to inline these methods?
Now I understand why you want refcounting fully handled at compile time...

DoDi