Mailing-List: contact lucy-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of loganbell@gmail.com designates
 209.85.215.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20120105184129.GA30433@rectangular.com>
References: <20120105073824.93378238890B@eris.apache.org>
	<20120105184129.GA30433@rectangular.com>
Date: Thu, 5 Jan 2012 11:33:12 -0800
Message-ID: 
 <CAHkJ3CteYmxUisPAoCVMrqF3GPFriQk3XwC+kzsCtYMRdGPaTQ@mail.gmail.com>
From: Logan Bell <loganbell@gmail.com>
To: lucy-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=001517475f76bf9fb504b5cd006f
Subject: Re: [lucy-dev] Ruby allocation/initialization

--001517475f76bf9fb504b5cd006f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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=92re implementing doesn=92t use any data other th=
an
Ruby instance variables, then you don=92t need to write an allocation
function=97Ruby=92s default allocator will work just fine. " If I understan=
d
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
=93back-door means.=94 One example is when objects are being deserialized f=
rom
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.

/Logan


On Thu, Jan 5, 2012 at 10:41 AM, Marvin Humphrey <marvin@rectangular.com>wr=
ote:

> On Thu, Jan 05, 2012 at 07:38:24AM -0000, logie@apache.org wrote:
> > URL: http://svn.apache.org/viewvc?rev=3D1227512&view=3Drev
> > 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 runni=
ng
>      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
>
>

--001517475f76bf9fb504b5cd006f--