[Lazarus] Delphi post-XE3 roadmap

[Lukasz Sokol]

On 29/08/2012 11:11, Bernd wrote:
> 2012/8/29 Lukasz Sokol <el.es.cr at gmail.com>:
> 
>> BTW, Frankly, would it not be easier/less error prone if the
>> FDisconnectLock.[Acquire|Release] did that ? (i.e.
>> increase/decrease the RefCount of Self as well as acquire/release
>> the lock ?) It seems /logically/ correct : there is /one/ more
>> activity associated to this object, so it can't be freed before
>> it's done ?
> 
> Yes, you are right, that would consequently be the most logical
> place for these calls. It was just a pragmatic quick fix to narrow
> down the source of the problem. I'm not yet 100% satisfied with this
> entire connection object and everything that surrounds it (and the
> multiple ways it must be able to end its life: it must be able to
> free itself (happens on the network thread) and it must be able to be
> disconnected and freed from the outside from the main thread).
> Athough now it seems that all crashes are gone I somehow still don't
> really like the code yet.
> 

Well. 
>From before I remember even in Delphi (maybe), calling Self.Free, or equivalent,
even as a last line ever, was an invitation to memory corruption and AV's.
(LCL/VCL Forms come as example : you don't free one from within, period. You call Close,
and OnClose you decide if you want to Hide it or whatsit-called-option-to-destroy - but
only the parent was able to free its child - in this instance, Application's Idle loop
(again, IIRC).)

So I imagine Object Pascal way would be to have the TConnection as a child of some
governing object, that would only ever call its .Free destructor, and of itself never
getting destroyed (the governor). And I see where the temptation to include the /common/
cases of such constructs into a Garbage Collector comes from... in programs without TApplication.

(again all this is IIRC and IMVHO)
(I sense we got a bit OT?)
L.