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