[ruby-talk:00505] Re: One question about classes written in C.

Hi,

In message "[ruby-talk:00502] One question about classes written in C."
    on 99/07/16, [e-mail] <[e-mail]> writes:

|   If I want to implement a new class, it seems to me, that I EVER have
|   to go the Data_Make_Struct way! Is that correct? I assume the way via
|   defining a own structure like

As Gotoken said, use Data_Make_Struct to avoid future magic number
conflict.  Type magic number should be lower than 0x80, so We have
only 127 possible magic numbers.  I'd like to reserve them for the
future internal types.

|   1. In his implementation of `frac-1.1', Takaaki Tateishi has used a
|      macro, which I have missed in `ruby.h'. I have generalized and
|      renamed it. Now it becomes:
|
|      #define IS_A(obj,klass) \
|	    ((rb_obj_is_kind_of((obj),(klass))==Qtrue)?1:0)
|
|      Could we get it into `ruby.h', please? I feel I will often use
|      such a test?

Hmm, I think using is-a too much is bad funciton; use polymorphism
instead, if possible.  I think I'm not going to add it not to
encourage using IS_A.

|   2. I think, that the macro ALLOCA_N should only be defined in
|      `ruby.h' if the function `alloca' is also available. The module
|      `frac-1.1' e.g. use that macro. There will probably be problems,
|      if I try to use that extension on a platform without an `alloca'
|      function.
|   
|      If you, however, claim that all platforms would have that
|      function, you could remove the test of `alloca' existance at
|      whole, couldn't you? ;-)

Foe the plaforms which does not have alloca(), we supply portable (but
inefficient) substitution.  See missing/alloca.c.

|   3. You know, I was very confused about the term "true" garbage
|      collection. I have read the advertisements again and I think,
|      that I understand now, how I could got such wrong impression.
|      May I explain?
|
|      Often in the docs it is mentioned that Ruby has "true" GC.
|
|      On the script level, that is also true for Python, Perl, Tcl and
|      the like.

Actually no, at least for Python (and maybe for Tcl, but not for
Perl).  Python uses reference counting, so that circular references
would not be collected.  Python users should aware it uses non "true
GC", and cut the unused circular references, otherwise memory leak
will happen.

Perl do use reference counting, but it also do the real GC (mark and
sweep) periodically.  So it can claim to have "true" GC.

|      But the difference will be found on the C level! Here Ruby differs
|      from all these languages. If here, anybody simply speaks from true
|      GC, I silently assume, that this is also valid for normally
|      allocated memory. Especially if I have a look into the sources.
|      Here I often can find something like
|
|         ptr = ALLOC_N(<type>, <count>);
|
|      AND NEARLY NO CALL TO `free(ptr)'. If I do not know the
|      dependencies, I really can get the impression, that there is a
|      "real" GC on work!

Maybe I had better emphasize `less memory management in extensions',
not "true GC". :-)

|   4. I have another Feature request: Could we think about a way, how
|      to connect an C variable with an instance variable? If ruby set
|      that instance variable, the corresponding C variable should also
|      be set. If the C variable was set, the corr. instance variable
|      should also be influenced.

Hmm, instances are many.  The relation between C variable and instance
variables should be 1 to n relation.  How can Ruby handle that
relation?  Could you explain more about your idea?

|I hope, when I have finished my extension, I can publish it in contrib,
|as example to show other beginners how to write extensions. I am
|currently writing a medium sized README, in which I try to explain some
|experiences I have made during that trip. I hope that you and others
|could read it and propose modifications or correct things, where I was
|wrong!

I advice you that 'do not use T_POINT' in your extension. :-)

                                                matz.