[fpc-devel] Breaking change in FPC 2.6.1

[Marco van de Voort]

In our previous episode, Ludo Brands said:

> > 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.

Summary: afaik I wanted the change to go over as quickly as possible, but I
assumed that a more freebookmark based approach was eventually the way to
go anyway (and I still think that, unless the "virtual" is removed in XE2)

I can only assume I chose pointer for minimal modifications AND to make
people aware of it, so that unfreed bookmarks would show up in the
heaptraces, so that at least the FPC+Lazarus codebase properly calls
freebookmark everywhere.
 
> > 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.

Yes, for instance if there are external resources like cursors or locks
coupled to it, and it is not just a matter of freeing that single block of
memory. 

> IMHO that would be only the case for those datasets that were developped
> with the intermediate non-managed Tbookmark=pointer.

And I hope for all future datasets and code using it. Since the method is
still virtual, and I could take even the old "string" version simply only as
a label or handle to an external resource.  (cursors, indexes, locks)

The fact that it is an automated string then only buys the freeing of the
label, but doesn't solve the problem. There is no ability to run code that
way.

> 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.

Afaik the assumption that it is /modeled/ as managed is simply wrong. It is
currently modeled as NOT managed, it is just that for historic reasons
managed works for the default base TDataset. But descendents don't have to
support that (e.g. if they don't support old Delphi versions, something that
is increasingly happening, with the first D7 supports disappearing)

> > 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.

Ideally, in time we want the interface to be the same as current Delphi's.

But note that changing it to tbytes IMHO doesn't mean you can skip
freebookmark, if you do that you cut corners, and program for a specific
tdataset
 
> > 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.

I think freebookmark is not historic. Code that treated tbookmark opague,
and called freebookmark remained working with the change of tbytes. That is
good design. It also gives a lot of freedom to dataasets to implement
bookmark support.

Opague type use is a good habit.

> Delphi created a mess. Don't let us add to it. 

(to be honest, I think that the tbytes stuff is the mess. Bowing to
pressure, compromising design. But I bet the idea is still that you call
freebookmark)