* 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)->on_button_undo_clicked =
glade_phone_ui_real_on_button_undo_clicked;
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
_______________________________________________
Vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
