On Fri, Apr 26, 2013 at 4:43 PM, Nick Wellnhofer <[email protected]> wrote:
> In that case, I would simply cast const away. Without const methods, const
> Strings would be almost useless.
OK, how about another approach which avoids the need for const methods?
Thanks to a suggestion from Nate a while back, our INCREF returns a reference,
facilitating an assignment idiom.
self->string = (String*)INCREF(string);
What we implemented String's Inc_RefCount method to return a clone if it's
allocated on the stack?
String*
Str_inc_refcount(String *self) {
if (self->origin == NULL) {
return Str_Clone(self);
}
else {
// SUPER ...
}
}
If we go that route, we might reconceive INCREF and DECREF as CAPTURE and
RELEASE: you "capture" and "release" a reference which may or may not point at
the object you're operating on, as opposed to mutating a specific object's
refcount by incrementing or decrementing.
> That's what motivated me to merge strings, substrings and zombie strings
> into a single class. In my proposal, there isn't a separate ZombieString
> class anymore.
Yes, I liked that very much! Building on your success... ;)
It still seems less than optimal for String to be abstract or UTF-8-specific,
and to require that client code assume that it's dealing with instances of
concrete subclasses. It's also strange for String to be extendable when
practically speaking it's sealed. There's a good argument to be made that all
of the core classes except Obj itself should be final.
Clownfish needs to support multiple internal encodings for String, but does
any one build of Clownfish need to support multiple encodings at once? How
about making the decision at build time?
Marvin Humphrey
