[fpc-devel] Proof of Concept ARC implementation

[Sven Barth]

On 29.10.2014 16:45, Jonas Maebe wrote:
>
> On 29 Oct 2014, at 16:30, Sven Barth wrote:
>
>> On 29.10.2014 14:23, Jonas Maebe wrote:
>>>
>>> Apple also supports mixing ARC and non-ARC code in Objective-C, but the
>>> only way this works is by requiring the programmer to manually perform
>>> the reference counting in non-ARC code. I don't think there's any quick
>>> hack possible that allows you to mix them transparently without a lot of
>>> pitfalls.
>>
>> We can of course also provide means to manually do reference counting
>> (will e.g. be necessary for TStringList if one has code that abuses
>> Objects[]...).
>
> That's indeed only useful if you then also require that all code not
> written in non-ARC mode performs manual reference counting (like Apple
> does). Having it as "a possibility" does not solve the problem of
> unpredictability.

And how does Apple enforce this?

>> Nevertheless if one mixes refcounting and non-refcounting code with
>> care (maybe we can add optional warnings/hints when passing instances
>> between ARC and non-ARC code) it should work.
>
> Then you have to give a hint/warning for every inherited call inside a
> refcounted class that inherits from a non-reference-counted class,
> because it passes the refcounted instance "self" to non-ARC code. It
> completely destroys the concept of encapsulation that you shouldn't have
> to know, and in some cases even can't know, what methods do with their
> parameters or with self. Your code may work with one version of the
> parent class and suddenly break with the next version. Being careful is
> simply impossible with this way of working.

Self is weak anyway, thus not reference counted. Problems should thus 
only surface when passing Self to other code.
Note: currently in the branch Self is completely weak (remember the mail 
in which I commented regarding this?), but in the end the reference 
count should be changed if it is passed to a reference counted variable...

Regards,
Sven