Re: [Vala] enum typing
- From: Yu Feng <rainwoodman gmail com>
- To: Shawn Ferris <shawn ferris gmail com>
- Cc: Vala ML <vala-list gnome org>
- Subject: Re: [Vala] enum typing
- Date: Sat, 27 Jun 2009 11:50:38 +0800
On Fri, 2009-06-26 at 21:40 -0600, Shawn Ferris wrote:
Hello again,
As you know, I've been working on the Oracle OCI bindings. Now that it's
funcational, I wanna wrap it into a more friendly, vala style interface.
I would like more of the options as properties, but I'm not sure if
there's a special way to define them. EG:
using OCI;
public class Test : GLib.Object {
public OCI.Mode mode { get; set; default = OCI.Mode.DEFAULT; }
}
Vala doesn't seem to think this is a problem, but gcc pukes all over it,
and I sorta understand why. It's not really a type, it's a group of
values, but they're all int and I don't want to have to hard code that
fact if down the road oracle decides it shouldn't be.
Now, in the Vapi, I could do this to type args: (HType being the enum in
this case)
public int HandleFree (
void* handlp,
HType type
);
so, I'm not sure what the difference really is?
looks like you triggered a bug in valac about defualt property values of
non-native types.
Also, I was curious about separating api's into multiple vapi.. For
instance, the oracle one is huge, if I ever get to the point that the
entire thing is impletement (unlikely) but, to make it easy for myself,
I created oci_enums.vapi, oci_structs.vapi and oci.vapi for everthing
that doesn't fit in structs and enums.. Then I used oci.deps to pull in
structs and enums.. is that a good idea, or should the final product be
a single concatenated view of the three?
did you consider the possibility splitting the API into files by
functionality?
As always, appreciate any advice!
_______________________________________________
Vala-list mailing list
Vala-list gnome org
http://mail.gnome.org/mailman/listinfo/vala-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]