Re: [Vala] Putting vala in samba4

[Sam Liddicott <sam liddicott com>]

* Jürg Billeter wrote, On 15/07/08 11:47:

On Tue, 2008-07-15 at 07:55 +0100, Sam Liddicott wrote: 
  

...

The first struct I intend to wrap is struct ntvfs_ops, as that struct 
define my base object; see:
http://gitweb.samba.org/?p=samba.git;a=blob;f=source/ntvfs/ntvfs.h;h=5de8a8b6491cd7e0f81915907de5b4fbc8153a47;hb=v4-0-test#l43

It IS a virtual method table, which a particular module has to fill in 
with all the methods:
http://gitweb.samba.org/?p=samba.git;a=blob;f=source/ntvfs/cifs/vfs_cifs.c;h=844fa11cc5f584df597b0c791386b07354d08c98;hb=v4-0-test#l1089
but more complicatedly, along with a couple of attributes (ops.name, 
ops.type).
It is registered on line 1137

So I don't know where to start to wrap this, to be able to tell vala 
where to store the methods compatibly with samba.
    

That seems like you want support for virtual methods in compact classes
or maybe something like compact interfaces. 

Yeah, interfaces did come to mind after I wrote that.

Not sure to what extent we
want to support this. If you have concrete proposals, how Vala could
support this without being specifically tied to how the ntvfs_ops struct
works, we can certainly discuss this.
  

I think I am looking for some [CCode] directives that allow me to specify the storage of the method table and names of entries within it.

It should be possible to bind and use ntvfs_ops by declaring a delegate
for each vfunc type and adding a field for each vfunc to the bound
struct/class. You'd have to manually connect the delegates in some init
functions, then, just like in C, i.e. you can't use `override` like
that.
  

The less exciting way :-)

I think the first way was best; I like the _*_class_init to fill in the method table for me.

However looking at some generated C, I note that the virtual methods are exposed in a:
 struct _****Class
struct that has a pointer to the parent class Class struct and then all the virtual methods follow; a model which does not follow the ntvfs model or many of the common C models, which is pretty much a free-form struct that is already defined.

The question becomes whether or not it is essential that the _****Class struct follow the same pattern; i.e. are they typecast as each-other...  - or could it vary for some specific class hierachies.

It seems that this is not so important for simple use, where C code is generated like:
    PHONE_DIALER_CLASS (klass)->> i.e. PHONE_DIALER_CLASS is used to access the VMT wherever it may be, and after that it is access by identifier and not offset.

I note with surprise from another example of mine:
struct _PhoneDialer {
    GtkObject parent_instance;
    PhoneDialerPrivate * priv;
    char* namespace;
    GtkBuilder* xml;
    PhoneDialerwindow_widgets* widgets;
};

struct _PhoneDialerClass {
    GtkObjectClass parent_class;
    void (*on_button_undo_clicked) (GtkWidget* widget, PhoneDialer* self);
};

that there is no reference from the instance struct to the class struct, i.e. _PhoneDialer does not have a pointer to a _PhoneDialerClass, which perhaps makes it hard to ask an instance what class it is for non glib types; I guess there are directives to let me fill in such helpers, some can be seen in the glib vapi file, but I notice that G_TYPE_INSTANCE_GET_CLASS is not defined in any vapi files, although things like it are.

So the simple question has arisen, how strick id the _***Class struct, can an existing type safely be used instead of a new type being defined?

Sam