[ruby-talk:01927] Re: object creation

Andrew Hunt writes:
> 	>> Agreed, but here's my real question: suppose you have a
> 	>> non-built- in class such as MD5, which does not expose a
> 	>> C-level constructor (something like rb_str_new,
> 	>> rb_time_new, etc).  What is the preferred way to create a
> 	>> new MD5 object from C code?
> 	>
> 	>Hmmmm! I would say that this is impossible, at a first
> 	>glance. This MD5 class has to implement a C function that
> 	>would be connected to MD5::new at Ruby level. So you would
> 	>have to search something like (example taken from
> 	>ext/gdbm/gdbm.c):
> 	>
> 	>   rb_define_singleton_method(cGDBM, "new", fgdbm_s_open, -1);
> 
> If a class defines it's own new (or open, or whatever) wouldn't it
> be easier just to call that method using the funcall mechanism?  

It would be easier, of course. But it would also be slower and would
invoke the interpreter again. I would code an own local function, that
call the fgdbm_s_open function directly. Then I would use this local
function in my extension.

If I program in C, I would not want the parser and evaluator to be
invoked to often. Otherwise I would end with write the app totally in
Ruby, store it in an char* and pass it to the eval-loop.

> Of course, the preferred route would be to define a C-level
> constructor (as the built-in classes have).  But if that didn't
> exist, as is the case with MD5, wouldn't it be better to call the
> "new" method through a funcall rather than poking around directly in
> its implementation?

See my remark above. But of course, the performance penalty would not
be that much high, that I couldn't do it the way you propose. It is a
matter-of-taste at the end, IMHO. That I wouldn't do it does not mean
you shouldn't do it too. :-)))

> 	>I admit, it looks a little bit complicate. That is the
> 	>reason, extensions should have a method like rb_str_new2
> 	>(that I would call an C constructor) too, if they are
> 	>intended to be used on C level.
> 
> I agree completely; I think all extensions should define a C
> constructor - I shall make that recomendation in our book...

Hmm! Because you mention the book ... 

If I code a class in a C extension there will be no problem if I
derive other classed coded in Ruby from it. But if I want to code that
child class also in C there will be a problem if we follow the
'normal' official way of handling such things in the 'new' method.

In [ruby-talk:00631] I had propose a way, that could also make
possible to simulate inheritance for derived child classes coded in C
too. The way would be transparent for child classes coded in C or in
Ruby. 

I had asked the member of ruby-talk to tell me what they think about
it, but hadn't seen any answer afterwards. So I had feared that it was
again a stupid proposal from me ...

Now seeing messages like [ruby-talk:1875] or [ruby-talk:1894] it seems
to me that this could be what I had proposed in the past. Perhaps you
could re-read my old post. If you cannot find a flaw in it, I would
propose to mention this way also.

> 
> /\ndy
> 

...

-- 
Clemens Hintze  mailto: [e-mail]