Re: Lacking of a ref-counted string.

["Havoc Pennington" <hp pobox com>]

Hi,

On Sat, Aug 23, 2008 at 8:29 AM, Freddie Unpenstein
<fredderic excite com> wrote:
> This issue comes up repeatedly, and each time the response is to ask for proof that it would make things better.
> How about the opposite, where's the proof that it would make things worse?

In software, everything starts with proof it makes things worse,
because changing code definitely takes time and introduces bugs ... I
mean that in all seriousness. This is especially true for API changes
that ripple through hundreds or even thousands of third-party apps,
which is what most GLib changes are. So if you do a pros and cons list
on any GLib change, there is a big con, right up front, 100% known.

I think that leads to an appropriate conservatism. For code that's in
an app and not used by anyone else, you wouldn't want to see the same
conservatism.

Anyway... on ref-counted strings, I don't really remember this thread
happening before (archive link?) so I'm not sure it comes up
repeatedly.

I'm not sure anyone on this thread has seriously proposed changing the
whole stack of GTK APIs to use refcounted strings - certainly nobody
has really written up what that would mean in detail, and tried to
analyze pros and cons. If you're proposing this, I would say step back
and explain what the actual proposal is, before addressing the
objections ;-)

> Exactly how much slower would GTK get if it had to ref-count instead of copy strings everywhere

If you're talking about converting existing APIs to refcounted
strings, that's a very different proposal from just adding some kind
of refcounted string feature. It would break thousands of apps, or
else duplicate hundreds of API entry points ...

> How much more complicated is it for bindings (most of which use ref-counted strings themselves) to wrap a reference to a
> string instead of wrapping a whole new copy of the string.

This one I can answer: most bindings would have to copy the strings
into a native string type just as they do now. A few, maybe Vala and
C++, could conceivably avoid the copy. So refcounted strings would not
matter much for bindings in general but might help the C-like
bindings.

> The last argument I often hear against ref-counted strings, is thread-safety.

I thought people were using that as an argument _for_ refcounted
strings. (Though I agree with your sentiment that GLib's approach to
threads is not to make each individual data structure transparently
thread safe.)

> But even just ref-counting alone would help, and even if it hurts efficiency a little, I fully believe it would be worth it.

While I don't know what you're proposing in detail, I can't imagine
efficiency is the issue. Huge API changes would be a much, much more
significant factor. The other potentially obvious factor is
programming convenience; refcounted strings in the GTK APIs would make
some things easier, but other things (such as passing in a string
literal) harder. Illustrating a particular proposal by "porting" some
sample apps might demo these tradeoffs.

Havoc