lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject [lucy-dev] Ruby allocation/initialization
Date Thu, 05 Jan 2012 18:41:29 GMT
On Thu, Jan 05, 2012 at 07:38:24AM -0000, logie@apache.org wrote:
> URL: http://svn.apache.org/viewvc?rev=1227512&view=rev
> Log:
> Added CFCHierarchy_allocate in order to play nice within
> the ruby object allocation patterns. Updated CFCHierarchy_new to
> call this function instead when creating the base CFCHIERARCHY_META
> struct.

Summarizing and continuing an IRC discussion:

The example code in the pickaxe book's appendix on the Ruby's C API (free
download linked off of <http://pragprog.com/book/ruby3/programming-ruby-1-9>)
for defining a class requires both an allocation function and an
initialization function.  We have the initialization function already: 

    CFCHierarchy*
    CFCHierarchy_init(CFCHierarchy *self, const char *source, const char *dest);

However, before this commit, we did not have an allocation function which met
Ruby's needs:

    * Take no arguments.
    * Return a "blank" object.  (Essentially, something suitable for running
      through the initialization function.)

We have CFCHierarchy_new(), but it takes arguments and returns a complete
object.

    CFCHierarchy*
    CFCHierarchy_new(const char *source, const char *dest);

Here the new allocator:

    CFCHierarchy*
    CFCHierarchy_allocate();

I understand the need for zero-argument constructors e.g. when deserializing,
though I don't completely understand whether the allocator is an absolute
requirement for defining a Ruby class extension or just a quirk of the example
code.

If it's a requirement, we'll presumably be modifying Lucy's classes eventually
and adding allocators there to accommodate Ruby.

Marvin Humphrey


Mime
View raw message