Considering the multiple discussions recently here done on the "New
Strings", that also introduce multiple compiler-relevant brands of a
single type, IMHO there are some restrictions to be payed attention to,
if the user is enable to use both ref-counted and not ref-counted
Objects. Otherwise we will be facing some dangerous ambiguity.
One way to avoid the ambiguity is to only provide a single brand TObject
type i.e. the choice would be completely dynamic by a property
"IsRefCounted" to TObject.
If the runtime overhead for this is considered to be too big, two
TObject Types (or brands of the TObject type) could be provided.
But here additional considerations are necessary:
The two brands need to be incompatible. A simple assignment of one to
the other needs to be forbidden
If such assignment is supported by the compiler, some kind of automatic
conversion needs to be implemented (see New Strings encoding conversions)
To decently support lists of such objects (TList), there are some
alternatives:
(1) different incompatible lists types are provided for either brand
(2) TList is provided with only one brand and auto-conversion is forced
(This is how NewStings work with TStrings in Delphi, IMHO inappropriately)
(3) An additional type is provided that is fully dynamic and hence
supports all brands (This is how I would prefer NewStings to work with
TString)
(4) My favorite here: The ref-counted type is "compatible" meaning that
...(a) you can assign a not ref counted object to a variable of the ref
counted type brand. Here (e.g.) the ref count is set to -1 meaning "not
ref counted"
...(b) you can't assign a ref counted object to a variable of the not
ref counted type brand
...(c) TList is provided only for ref counted TObjects. Auto-conversion
is done (setting the ref-count to -1) when moving a not ref-counted
object into the list.
-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
