Re: [Vala] error on property;

[Sam Liddicott <sam liddicott com>]

Yu Feng wrote:

On Wed, 2008-08-20 at 18:54 +0100, Sam Liddicott wrote:
  

Yu Feng wrote: 
    

Hi Alex,

Fortunately I was dealing with the same problem too.
The key is for a property, you almost always want a weak string, and
manage the string in the object. In other words, this code will be fine:

public class Info.PersonInfo {
  private string fio_;
  public weak string fio {
    get {
       fio_ = get_fio();
       return fio_;
  
      

I don't think that is safe.
    

I hope vala will strdup the returned value when I do a
string foo = personinfo.fio.
  

I think you are right; my mistake... I was confusing what you did with an error I had previously made :-)

Although next time somebody reads fio, the old fio_ will get free'd and we had better hope the old user has finished with it; it may be better to only generate fio_ once for the life of the object.

I agree that it is problematic; part of the issue seems to be that
strings can't be reference counted and (apart from "weak") are also
immutable. The strdup's in generated code drive me mad.
    

I've pointed out a 'solution' to them is to abandon any attempt of
managing the strings and leave the job to programmers in the other
post(the 'workaround' one)
  

Yeah :-) I'm trying to think of a solution that covers both problems.

Vala seems based on gobject and does a very good job of making gnome projects simple, but I think we're trying to make it cover non-gnome too.

I shall mention again that the talloc allocator not only ref-counts
and has owners but has destructors AND is type-safe. Talloc for string
management at least would make things much simpler. However it could
complicate transferring ownership to glib libraries which would use
the wrong free function.
    

In one word, talloc is not in GLib and doesn't fit into the GLib backend
of Vala. right? So far what I can understand is vala hasn't yet separate
the GLib backend from the core compiler.
  

Vala will always want to be good for glib, but I agree that a keeping the language features without glib will be good too, it's something I'm working on.

I've got indirect subclassing working where an instance has a pointer to the parent instance which has a pointer to the child instance, and that complicated valainstancecast quite a bit; I stll need to sort out construction and instantiation for this; but I really need to have support for talloc ref counting.

I'm still convinced there is something in my malloc pool idea where a pointer (by examining against memory ranges) can be efficiently pinned down to a malloc pool and malloc pool handler, which bestows features or interfaces on the object being pointed to. For best efficiency, each malloc system will need it's own anonymous mmap'd range to allocate from in order that the pointer can be identified to that handler, but sub-allocating large blocks from the real pool will work at a pinch.

There are still issues with fixed-length char arrays as part of a larger allocated struct which are not real char* but may look like it when passed as an argument...

So I'm still thinking... but I think vala needs two string types, a boring char* (with optional max-len and option count) and a proper string...

Sam