Re: Lacking of a ref-counted string.

["Havoc Pennington" <hp pobox com>]

Hi,

On Wed, Aug 20, 2008 at 8:47 PM, Yu Feng <rainwoodman gmail com> wrote:
> First, it is very difficult to manage a string without a reference
> count. The current vala implementation is to assume that strings are
> immutable, and to copy the strings almost everywhere where increasing
> the ref-count should be used. The copying mechanism produces workable
> code, but doesn't work in a efficient way. This is where it hurts.
>
> Secondly, vala doesn't introduce any additional dependency other than
> GLib, to implement it in VALA level, the only way is to embed it in the
> compiler. A compiler with embeded code to do a ref-counted string
> doesn't sound nice. This is why I think it should be done at GLib level.
>

If we think of GLib features as either for C, or for language bindings
in general, or for vala, this particular feature seems like it would
be *only* for vala - refcounted strings would be pretty strange in
plain C, and just overhead for other language bindings that already
have native string types they have to convert gchar* to.

Putting only-useful-for-vala features in GLib would seem odd to me.
Just one opinion, though.

Can't vala do the same optimizations a C programmer would do by hand
in most cases - avoiding a copy for a const char* that is only stored
temporarily in local scope, for example? For other cases, a plain C
program would have the same inefficiencies as vala it seems like, and
they are not fatal inefficiencies...

What about a libvala? I guess vala is supposed to have this property
that it doesn't create dependencies in distributed tarballs, but that
design goal has brought us autoconf and libtool in the past... not
sure I'm sold on it.

Or then, embedding it in the compiler does not seem like a very big
deal - it's just two operations ref and unref, both of which are
trivial and can just be inlined...

Havoc