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. > > > > _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
