lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Logan Bell <>
Subject Re: [lucy-dev] Ruby allocation/initialization
Date Thu, 05 Jan 2012 19:33:12 GMT
In regard to the allocation function and the need to create an empty object
has had me digging a bit more in the pickaxe book. The allocator is only
needed "if the object you’re implementing doesn’t use any data other than
Ruby instance variables, then you don’t need to write an allocation
function—Ruby’s default allocator will work just fine. " If I understand
that correctly, since our (Clownfish::CFC::Hierarchy) object does need data
then we need to allocate the space up front in the allocator function.

Further it goes on to outline reasons why this is necessary ( marshaling as
you pointed out being one of them ):

"One of the reasons for this multistep object creation protocol is that it
lets the interpreter handle situations where objects have to be created by
“back-door means.” One example is when objects are being deserialized from
their marshaled form. Here, the interpreter needs to create an empty object
(by calling the allocator), but it cannot call the initializer (because it
has no knowledge of the parameters to use). Another common situation is
when objects are duplicated or cloned."

It might be worth doing some code diving on the ruby end to see for sure,
but I can see value in in having constructors that accept no arguments.


On Thu, Jan 5, 2012 at 10:41 AM, Marvin Humphrey <>wrote:

> On Thu, Jan 05, 2012 at 07:38:24AM -0000, wrote:
> > URL:
> > 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 <
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message