Re: goops C interface

[Dale P. Smith]

Dirk Herrmann wrote:
> 
> SCM sd1, sd2, cd, cls;
> sd1 = scm_goops_make_slot_descriptor ();
> scm_goops_slot_descriptor_set_name (sd1, "slot1");
> scm_goops_slot_desctiptor_set_init_value (sd1, SCM_BOOL_F);
> [... further initialization of sd1]
> sd2 = scm_goops_make_slot_descriptor ();
> scm_goops_slot_descriptor_set_name (sd2, "slot2");
> scm_goops_slot_desctiptor_set_init_value (sd2, SCM_BOOL_F);
> [... further initialization of sd2]
> cd = scm_goops_make_class_descriptor ();
> scm_goops_class_descriptor_set_name (cd, "myclass");
> scm_goops_class_descriptor_add_slot (sd1);
> scm_goops_class_descriptor_add_slot (sd2);
> [... further slots added to cd]
> cls = scm_goops_make_class (cd);
....
> The idea, however, is taken from the way guile's smobs are currently
> initialized. This way extensibility is granted, since extending for
> example slots does not invalidate existing code since there are only new
> functions added. Readability is also quite nice, as can be seen from the
> current code examples for creating new smob types.

I kind of like this idea.  It sort of makes up for the lack of keyword
arguments in C.  Although I don't like function names that don't fit
into 72 columns ;^)
"scm_goops_class_descriptor_set_init_value_with_some_other_argument" 
(just joking! really!)

I'm not sure if it really matters all that much, but would a structure
based api (which is basically built at link time) be any faster that a
function call api?  I'm thinking about looong initalization times.  It's
probably not going to matter much, just thought I'd mention it.

-Dale

-- 
Dale P. Smith
Altus Technologies Corp.
address@hidden
400-746-9000 x309