Re: let's stop freezing interfaces containing old string types

Dan Mosedale wrote:
> Heikki Toivonen wrote:
> 
>> Dan Mosedale wrote:
>>
>>> I would like to propose that going forward, interfaces which still 
>>> have old string types (|string| and |wstring|) not be allowed to 
>>> freeze that way; conversion to the new types (|ACString|, 
>>> |AUTF8String|, |AString|) would be required.
>>
>>
>>
>> That way you would force the clients to link xpcom with their 
>> applications, right? In some cases they might just want to load our 
>> DLL, call a function with char* data and be done with it...
>>
> 
> Just the string and/or xpcom glue libraries, I think.  Perhaps someone 
> who knows more can correct me...
> 
> Dan
> 


When an interface is mark frozen, this of course is suppose to mean that 
their parameter types are frozen.  We have broken this rule with many 
API freezing.  Note the recent necko api freezing and the status of the 
string classes necko uses.

Interfaces moving forward that require strings should be using the 
nsAString, nsACString, and nsAUTF8String.  Of course, currently even 
these virtual classes are not frozen (see 
http://bugzilla.mozilla.org/show_bug.cgi?id=125389).

The idea behind making the string library resuable is so that it can be 
linked into the component, plugin, or embedded application.  In this 
way, clients can use a snapshot of the current implemention while 
allowing the trunk to continue to evolve.

If you look at the xpcom/sample examples.  Imagine that you wanted to 
build the xpcomsample component and have it work in different versions 
of xpcom.  The code does something like this:

nsXPIDLCString str;
rv = mysample->GetValue(getter_Copies(str));

Clearly, nsXPIDLCString is an unfrozen helper class and will probably 
never be frozen.  What to do?  Well, the component can (and should) link 
the string library directly into itself.  In this way, the code will be 
found in this static lib instead of xpcom.so.   (also see 136756).

So, you say "don't use nsXPIDLCString".  Well maybe.  But how do you 
construct a nsAUTF8String to pass into some of the mozilla api's? It 
sure would be nice to be able to reuse the implemention that mozilla 
has, right?

I hope this helps,

Doug Turner
[email protected]