Il 01/05/2012 22:05, Sven Barth ha scritto:
On 01.05.2012 22:03, Sven Barth wrote:
On 01.05.2012 20:15, Giuliano Colla wrote:
Il 01/05/2012 17:08, Michael Van Canneyt ha scritto:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As already mentioned in this thread, a mere hint about "may change
somehow, in the next version" is of no real use. IMO "deprecated"
means to the user that he should change his code *now*, in
anticipation of the coming change. This obviously is not the case
with the breaking change of the bookmark type, where *no* workaround
exists in the current release.
Instead of repeating the remark, suggesting a solution would be
useful.
Criticism is easy. Coming up with solutions obviously much less so.
I never used TDataset.Bookmark, and I'm not likely to use it in future,
so my attitude is that of an external observer, which might be
completely unaware of implications, but, as a general rule, wouldn't it
be wise to surround with an {$mode Delphi} all changes made to comply
with Delphi whims, to satisfy those who need Delphi compatibility, and
keep for the rest of the users things as stable and consistent as
possible, avoiding whenever possible to break compatibility with
existing code?
You can not "surround" code with {$mode Delphi}. It's a unit global
option and also it only changes syntax and semantic handling in the
compiler not code in the units.
Also we are talking about three kinds of Delphi compatible here:
* pre-Delphi 2007 for which used String
* Delphi 2007 which used Pointer
* Delphi 2009 and newer which uses TBytes
This is another reason why using something like "{$mode delphi}" would
be useless here.
Well {$mode Delphi} was just a way to illustrate the point, which could
perhaps obtained with some {$ifdef Delphi-pre07} or {$ifdef Delphi-07}
or {$ifdef Delphi-09} or whatever. Leaving whoever doesn't define a
Delphi compatibility to take advantage of a sane fpc way.
Giuliano
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
