[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: NSString changes breaks...
Re: Re: NSString changes breaks...
Tue, 31 Oct 2000 20:47:11 +0000
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
> >| > 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
> 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*
> GSWElementIDString has no specific init method).
> 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
> 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
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
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
> >| (at least) -replaceCharactersInRange:withString:, -length,
> >| 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
more accurately, you can't re-use the concrete implementations already in the
the upside is that the owner of the cluster (ie the developers of the base
is able to apply lots of optimisation techniques and to rework the concrete
without having any effect on user code.
The methods in the abstract base class all work in terms of a few primitive
rather than by accessing ivars directly. This means that your subclass has to
the ivars and implement the primitive methods as well as any initialisers you
You then get a working (but inefficient) subclass, and you optimise by
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
what you want is simply to add a category to NSMutableString so that *all*
string objects will have your methods available. The code change required to
is trivial and your existing method implementations should not need to change.