On 11/16/2011 10:44 AM, Marco van de Voort wrote:
It's a mix of all three actually. It is typed(A), there are two (B)
implementations, and the memory layout of both implementations have
similarities that makes Rawbytestring possible, making rawbytestring the
base memory representation the others "inherit" from (C).
Finding (C) is a bit of a stretch though. A and B are way more true than C.
What do you mean by "true". If you mean "it's more true that Delphi
works similar to that" the question, is if it is really a good design
goal to do an implementation that is closest possible to what DXE
provides, regarding that (from what I read, I don't have XE to test it)
the XE definitions to me seem like a rather chaotic and hardly
understandable mix of strong typing and dynamic encoding.
A is from the type system view.
Yep: no dynamic typing. (As there is no dynamic encoding this obviously
is not at all Delphi XE compatible, neither regarding the definition nor
regarding the implementation.) A RAW type, allowing for multiple
encoding types, is not possible here.
B is from the implementation (runtime
helpers) view.
Nope it's just a definition of a pure dynamically typed string
definition system. Implementation details were only mentioned to try to
make clear what I meant. (As there is only one String type and there is
no way to have the name of a type denote the encoding, this - regarding
the definition - obviously is not at all Delphi XE compatible.)
C only for rawbytestring (which is very, very limited and way
overestimated in all these discussions)
Nope. C defines the other new types as object-alike children of a
general "RAW" type. Here we have as well a "RAW" type, as multiple types
the names of which suggest a certain encoding the definition. This seems
to be rather similar to Delphi XE's. The implementation might be done
compatible to what XE does, but the intention of my post was to suggest
that _first_ a decent (strict, understandable, unambiguous) definition
should be done (as "Delphi-XE-compatible" does not seem to provide an
understandable straight forward wording) and _afterward_ evaluate the
implementation (i.e. take a look at doing how to improve what already
has been done).
-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
