Sven Barth schrieb:
Am 27.10.2014 21:00, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
Am 27.10.2014 17:20 schrieb "Hans-Peter Diettrich"
<drdiettri...@aol.com <mailto:drdiettri...@aol.com>>:
> Something like ShortString and AnsiString?
With the difference that Short- and AnsiString are assignable to
eachother while Jonas does not want that for reference counted and
ordinary classes.
Where would this matter? When TObject and TManagedObject are different
(base) types, a direct assignment of references is impossible.
Take unit Typinfo for example where quite some methods take a TObject
instance.
The TypInfo methods can determine the exact type of their arguments, and
act inside accordingly.
Or all those classes (TStrings, TObjectList, TComponent, etc.)
that somewhere take a TObject as parameter.
IMO containers play a different role in managed and unmanaged
environments. E.g. an TObjectList.OwnsObjects property is useless with
managed objects, and the circular owner/child and parent/child
references in several persistent classes deserve special attention and
handling, when used with managed objects. Similar considerations apply
to strings - should TStrings contain AnsiStrings or UnicodeStrings,
where despite their assignment compatibility the implicit conversions
between both can consume much runtime.
For such reasons I'd prefer a separate environment (RTL...) for only
managed and unmanaged objects, just like for AnsiString and
UnicodeString. But in combination such options would end up in many
different library versions, so that I do not really suggest such an
implementation. My dream are distinct FPC/Lazarus versions, designed for
compatibility with D7, D2009, Unicode, Mobile and whatever versions may
show up in the future. Then it should be possible to freeze the old
versions with all bugs fixed, and new features will be added only to
newer versions; this would eliminate all beforementioned problems,
resulting from mixing features of different Delphi versions.
IMO Delphi versions don't offer backwards compatibility for good
reasons, instead a purchased licencse allows to *also* use all older
versions, down to D7. What I'm missing here are bugfixes, because the
development of older versions is almost stopped as soon as a new version
is distributed. Known bugs are mostly fixed only in newer versions,
which introduce new bugs and features at the same time - good for sales
but bad for the customers. Since FPC/Lazarus are open source, user
groups may offer continued support for their preferred version(s), by
backporting bugfixes into these versions.
What do you mean with "virtual counting methods"?
Overriding these methods can enable/disable refcounting for a class,
and all classes derived from it. The default then can be to do nothing
(no counting).
But then it's the same reference counting as the COM one, because
without the COM reference counting those virtual methods would not be
called.
So you prefer to inline these methods?
Now I understand why you want refcounting fully handled at compile time...
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
