Re: Re[2]: NSString changes breaks...

[richard]

On Tuesday, October 31, 2000, at 06:58 PM, address@hidden wrote:

> On Tue, 31 Oct 2000 17:35:08 +0000 Richard wrote: 
>  >| The -initWithCharactersNoCopy:length:freeWhenDone: is currently a 
> primitive for 
> NSString and  
>  >| -initWithCapacity: is primitive for NSMutableString, but I'm not sure if 
> NSMutableString should 
>  >| implement -initWithCharactersNoCopy:length:freeWhenDone: using 
> -initWithCapacity: and -replaceCharactersInRange:withString:.  At present, it 
> doesn't. 
>  >|  
>  >| > GSWElementIDString doesn't have any ivar. It's just an empty class with 
> a category.  
>  >|  
>  >| If it has no ivars, how dis it expected to work? 
>  
> I think I haven't understand completely how NSStrings work. I was thinking my 
> GSWElementIDString class use NSMutableString ivars and methods. I've checked 
> the 
> previous core/base code and found no ivar in NSMutableString too. 
>  
> What I understand now, please correct me if I'm wrong: 
>         If I do a id s1=[NSMutableString new], I get a GSMString* 
>         If I do a id s2=[GSWElementIDString new], I get a GSWElementIDString* 
> (if 
> GSWElementIDString has no specific init method). 

Yes.

>         If I do a [s1 appendString:@"toto"], it call NSMutableString 
> appendString: method but 
> only because GSMString inherit from NSMutableString. 
>         Same thing for s2. 

Yes - though GSMString is free to implement its own version of appendString for 
greater efficiency.

> What I don't understand: 
>         GSWElementIDString was working well with no ivar and without 
> implementing -initXXX3. 
> Why ? In this logic, it wasn't possible because it shouldn't have ivars nor 
> -initXXX 
> methods. 

I agree - I can't see how it could have worked.  I grabbed a three week old 
version of gstep-base
from CVS, and looked at the source, and it doesn't look as though anything has 
changed that should
effect this (though I could easily have missed some subtle bug I suppose).

I see your code calls [GSWElementIDString new], and as far as I can see, the 
NSString code from
back then would create a new object in the same way as the current code - ie it 
would allocate
a GSWElementIDString and call init on it.  This should have been raising

> You can see the code in gsweb/GSWeb.framework/GSWElementIDString.[hm] 

Yes - as far as I can see, this shouldn't work.

>  >| To subclass NSMutableString, you should be inheriting from 
> NSMutableString and 
> implementing 
>  >| (at least) -replaceCharactersInRange:withString:, -length, 
> -characterAtindex: 
>  >|  
>  >| As the code stands now, you also have to implement the designated 
> initialisers - 
>  >| -initWithCharactersNoCopy:length:freeWhenDone: 
>  >| -initWithCStringNoCopy:length:freeWhenDone: 
>  >| -initWithCapacity: 
>  
> I can do this but why should I reimplement GSMString (for example) as I only 
> want a working 
> MutableString which differ only by the class name and few added methods ? I 
> can do this by 
> subsclassing GSMString but it's not the right way for portability. 

This is the downside of class clusters - you can't really subclass them easily 
- or,
more accurately, you can't re-use the concrete implementations already in the 
cluster -
the upside is that the owner of the cluster (ie the developers of the base 
library)
is able to apply lots of optimisation techniques and to rework the concrete 
implementations
without having any effect on user code.

The methods in the abstract base class all work in terms of a few primitive 
methods
rather than by accessing ivars directly.  This means that your subclass has to 
provide
the ivars and implement the primitive methods as well as any initialisers you 
use.
You then get a working (but inefficient) subclass, and you optimise by 
implementing
the methods you actually need in an efficient way.

However, for your purposes, as far as I can see, you don't need a subclass at 
all -
what you want is simply to add a category to NSMutableString so that *all* 
mutable
string objects will have your methods available.  The code change required to 
do this
is trivial and your existing method implementations should not need to change.