[fpc-devel] Breaking change in FPC 2.6.1

[Ludo Brands]

> > It broke also lazarus, MDO, rxmemds.
> 
> They mostly track 2.7.1 also, so then it should be just a 
> matter of enabling the right override for 2.6.x too (which is 
> what I had in mind)
>

I understand. Just wanted to clarify that, to my knowledge, all 3rd party
dataset descendants and some other programs using bookmarks are affected by
a change that wanted to minimize compatibility problems.

> > to the change to pointer isn't needed anymore for tbytes as it is a 
> > managed type. Why not bite the bullet immediately and just skip 
> > pointer? Avoiding incompatibility clearly failed.
> 
> That can be discussed. Specially if sb can confirm that it works.
> 
> I can however remember having read that freebookmark is still 
> recommended, and if I look at the method, it is virtual and 
> allows descendants to do extra processing. 
> 
> Probably because one can't trigger and event on freeing of an 
> automated type (at least not the array based ones, interfaces 
> is a differnet matter)
> 
> But I assume that is more for the dataset users that use 
> tbookmark than for internal use in tdataset implementers.
> 

That only would be useful if the tdataset descendant would add code around
Tbookmark that would turn a managed type into a partially non-managed type.
IMHO that would be only the case for those datasets that were developped
with the intermediate non-managed Tbookmark=pointer. I can't imagine a
tdataset implementer that would turn a managed bookmark type to an unmanaged
one on purpose. Delphi has lived 2-3 years with the Tbookmark=pointer
situation and probably has created there some backwards compatibility
problems. One more reason to jump to tbytes as quickly as possible.

> > On the Delphi forums, similar discussions have been going 
> on: people 
> > complaining about the different Tbookmark implementations 
> and having 
> > to change their code. Wish we could have learned from that.
> 
> That's why I waited a while with merging, so that initially 
> only 2.7.1 would be broken, and after a time without 
> complaints, I merged it because then it is only the matter of 
> connecting that change also with 2.6.1.
> 

I should have spoken up earlier then ;) The mention that the change to
tbytes is in the pipeline for trunk was what triggered my reaction.

> > > Freebookmark should have been called already, afaik it is at
> > > least since D2006, if not easier, and FPC also implements it 
> > > quite a while.
> > > 
> > 
> > 
> http://docwiki.embarcadero.com/Libraries/en/Data.DB.TDataSet.FreeBookm
> > ark
> > Quote: "TBookmark is an alias of TBytes. This means that 
> TBookmark is
> > automatically garbage collected when it goes out of scope. 
> Because TBookmark
> > does not need to free memory, the FreeBookmark method is 
> blank for the
> > default implementation." 
> 
> True. But it is virtual, so if your code is agnostic wrt the 
> dataset you use, or can be layered on top of otther datasets, 
> you should call freebookmark probably even if it doesn't for 
> the default dataset. 
> 
> IOW my idea is document and recommendthe way that always 
> works now, not shortcuts that may be possible for historic reasons.
> 

If we skip Tbookmark=pointer, at least fpc won't create new 'historic
reasons' for requiring freebookmark. Delphi created a mess. Don't let us add
to it. Having an empty freebookmark implementation will ease migration from
Delphi code that needed it at one point in time. Just make that new fpc code
won't need it.

Ludo