incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] Ruby allocation/initialization
Date Mon, 09 Jan 2012 02:30:30 GMT
On Sun, Jan 08, 2012 at 04:26:50PM -0800, Logan Bell wrote:
> Very interesting suggestions, I believe the code you supplied will
> work perfect.

According to the link you provided me in IRC, that's "Ruby 1.6 style":

    http://www.ruby-forum.com/topic/81100
    
    The only option I see is to use Ruby 1.6 style code and define a 
    Klass.new method for my classes.  The problems with this is it prevents 
    clean subclassing and object cloning.  

I tried the code and it does work -- but it seems that the approach you've
discovered via your research is more idiomatic for modern Ruby libraries, so
I think we should go with that.

> I did a bit more research in how other modules address this issue, and
> found that the allocator could generate an empty pointer that could
> then later be populated in the initialization function.
> 
> An example of this would be the following:
> 
> static VALUE cfc_hierarchy_alloc(VALUE klass) {
>     VALUE self_rb = Qnil;
>     void *ptr = NULL;
>     self_rb = Data_Wrap_Struct(klass, NULL, NULL, ptr);
>     return self_rb;
> }
> 
> static VALUE cfc_hierarchy_init(VALUE self_rb, VALUE source, VALUE dest) {
>     CFCHierarchy* self;
>     Data_Get_Struct(self_rb,CFCHierarchy, self);
>     self = CFCHierarchy_new(StringValuePtr(source),StringValuePtr(dest) );
>     DATA_PTR(self_rb) = self;
>     return self_rb;
> }
 
+1
 
> This pattern I found was being used in the ruby extension:
> ext/dbm/dbm.c. Doing it this way would allow us to still leverage the
> benefits of having an allocator (not certain if there really is any at
> this point). This is another way of at least doing it.

Nice work.

> If one uses rb_define_singleton_method, would we have any state issues
> later since that class is now a singleton? Or for our purposes, does
> it really even matter? Thoughts?

For Clownfish::CFC -- the compiler -- which is not designed to be extensible,
either implementation strategy would meet our needs technically.  However, IMO
we should use the modern idiom because it will be more familiar to people
spelunking the code.

For the code *generated* by Clownfish::CFC, and for Lucy as a library based on
the Clownfish object model, we will absolutely want to use allocators and
initializers.

In fact, when we create Clownfish::CFC::Binding::Ruby::Constructor, I bet it
will turn out to be cleaner than Clownfish::CFC::Binding::Perl::Constructor.
The Ruby allocation/initialization approach is closer to Clownfish's approach
than Perl's.

Marvin Humphrey


Mime
View raw message