Re: Lacking of a ref-counted string.

[Yu Feng <rainwoodman gmail com>]

On Thu, 2008-08-21 at 07:57 +0200, Ali Sabil 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.
> I am not quite sure, to me you seem to mix up copy on write string and
> shared buffers, copy on write strings are just an optimization, and
> they don't need to be in GLib. Concerning shared buffers, string are
> *not* used in vala for shared buffers, simply because a string in vala
> is a utf-8 encoded *immutablle* byte sequences. a byte buffer is
> represented using uchar[]. Right now vala supports is pretty young
> concerning array supports, they are hard to manage in the first place
> because of the C quirks (null terminated arrays, vs arrays with an
> extra parameter to specify the length).
> 
> To keep it simple, why don't you just write a ByteBuffer class
> inheriting from GObject ?
>  
I don't know see any reasons.

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