[Vala] [Fwd: Re: Lacking of a ref-counted string.]

[Yu Feng <rainwoodman gmail com>]

Mikkel also suggested a quite different way of treating immutable
strings. This can also do something related to copy-to-write?

Yu

-------- Forwarded Message --------
> From: Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>
> To: Yu Feng <rainwoodman gmail com>
> Cc: Havoc Pennington <hp pobox com>, gtk-devel-list
> <gtk-devel-list gnome org>
> Subject: Re: Lacking of a ref-counted string.
> Date: Thu, 21 Aug 2008 12:18:29 +0200
>
> 2008/8/21 Yu Feng <rainwoodman gmail com>:
> > On Wed, 2008-08-20 at 17:59 -0400, Havoc Pennington wrote:
> > > Hi,
> > >
> > > On Wed, Aug 20, 2008 at 3:10 PM, Yu Feng <rainwoodman gmail com> wrote:
> > > > Is there any particular reason that GLib doesn't provide a ref-counted
> > > > string and a ref-counted array type? Lacking them in GLib makes the VALA
> > > > language a real pain.
> > >
> > > I think you would have to explain more why this is an issue for vala,
> > > at least for me (maybe everyone else already knows)
> >
> > OK.
> >
> > Vala claims automatic memory management and a programming language on
> > top of GLib.
> >
> > 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.
>
> How about using a GStringChunk and apply some magic compile-time
> logic? Although I am not quite sure how it should be done - you are
> the wizards :-)
>
> It could maybe also make more sense to add some more API to
> GStringChunk as it is quite limited as it stands.
>
> Cheers,
> Mikkel