[gclist] Garbage collection and XML
Wed, 07 Mar 2001 15:50:06 +1000
I believe that some of your assertions about CORBA IDL are incorrect.
> where strings are immutable. It's really difficult to figure out *what*
> the DOM specifies, because
> - the primary specification is in CORBA IDL, in which every time you
> ask for a string the remote system sends you back a new copy
If you treat IDL as an abstract interface specification language ... as
DOM does ... it doesn't say how data type values are passed across an
interface. Such details only need to be considered when the IDL is
mapped to some target language(s) in some implementation context.
Even when IDL is used describe a client / server interaction; e.g. using
a conventional ORB and standard language mappings, data types (like
strings) are not always passed by copying. If the client and object are
colocated, the ORB may pass values by reference ... even in the case of
C++ where C++ types that represent the IDL data types are mutable. [One
of the rules that you must obey to write portable CORBA C++ code is that
a 'server' must not change values that have been passed as 'in' args.]
In the case of Java, it hardly matters which way 'string' values are
passed in the colocated case unless your code compares java.lang.String
values using '==' ... which is dodgy at the best of times!
> - the object chosen to represent strings in the CORBA IDL for the DOM
> is a *mutable* array of 16-bit characters
CORBA IDL doesn't define strings (or any other data type) as mutable or
immutable. Such issues belong in the CORBA language mappings, and different
mappings make different decisions. Furthermore, if you hand-map the IDL
to native APIs, it is entirely up to you how you address the issue.
> bindings is an *immutable* String of 16-bit characters.
The standard CORBA IDL -> Java mapping ALSO maps CORBA 'string' to Java's
'java.lang.String'; i.e. immutable arrays of UTF-16 characters.
You might argue that DOM should use a non-standard mapping for 'string';
e.g. to some object wrapper for an immutable array of bytes. This would
be more space efficient, but it would be a right royal pain to write
Java applications that used such a DOM API.