lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Wellnhofer <>
Subject Re: [lucy-dev] Proposal for implementation of immutable strings
Date Sat, 27 Apr 2013 14:27:12 GMT
On Apr 27, 2013, at 06:03 , Marvin Humphrey <> wrote:

> 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 ...
>        }
>    }

+1, seems like the safest and easiest solution. It means that we never have to clone host
language strings initially. We only have to make sure that we always use the return value
when INCREFing a String.

> 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.

Or RETAIN/RELEASE like in Objective-C?

> 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?

UTF-8 and UTF-16 are useful for filenames, so I'd say that any Clownfish build should support
these encodings. Using inheritance for encodings seems like a natural approach to me. Client
code wouldn't even have to care about which subclass it's working with. But I don't have a
strong opinion about how encodings are implemented internally.


View raw message