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

On 20 Jul, GOTO Kentaro wrote:
>  Hi Cle,
>  
>  In message "[ruby-talk:00506] Re: One question about classes written in C."
>      on 99/07/19, Yukihiro Matsumoto <[e-mail]> writes:
>  

[...}

>  I often use `coerce technic' for the default action:
>  

[...]

>  
>  It's an idiomatic phrase. Indeed, we have only the three concrete
>  classes as the numeric. 

Ahem! I feel I had not made very clear my opinions (once again ;-)

I understand and use that coerce technic. But here in my example I
cannot use it IMHO! My addition method is defined as:

   class Point
       def + (other)
          if other.is_a?(Point)
              return Point.new(@x + other.x, @y + other.y)
          else
              return Point.new(@x + other, @y + other)
          end
       end
   end

I think there is no way, I could use coercion technic, is there?

Furthermore there is an `Object#is_a?' method, and I can really not
understand, why matz doesn't want to adopt that macro. There are
checkers like `CLASS_OF' and `Check_Type'. But `IS_A' is not good? :-/

If I follow his statement, I should also not use `Object#is_a?', should
I?

>  
>  # I'll add SingleFloat and DoubleFloat in the near future.

May I ask, for what it would be good for?

>  
>  But you can use IS_A() macro if you need.  I would NOT like to stop
>  that :-)

I will not stopping to use it :-) I will also mention it in my tutorial.
;-)

[...]

>  I don't think it's nice because one doesn't have to set instance
>  variables in order to customize the class but she can use private
>  methods.

Ahem, yes. Okay, I have not thought so. Only that we would have a
possibility to check or correct the values of an instance var. But if I
think more about it, I feel, that this is for what the accessor methods
was made for.

So please forget about that feature on Ruby level! But on C level it
would makes sense, wouldn't it?

>  
>  >From the other point of view, customizing by instance variables seems
>  easy to cause bugs which are not easy to be found if the class is
>  implemented in C, i.e. in the situation where one can't see how an
>  instance variable is used inside of the object.

Perhaps I have got you wrong! Does that mean it is okay for C level, or
not?

Until yet, I have to decide, whether I want to use C internal
structures instead instance variables, or vice versa. A class `Point3D'
derived from a Ruby-coded class `Point' could use its instance
variables `@x' and `@y'. If the class `Point', however, is coded in C
and the coordinates are hold in a C struct, the class `Point3D' have to
use accessor methods to work with the internal data of the parent class
`Point'!

I am not very happy with that difference. So I think if we would be
able to connect such a C struct member with a instance variable, class
`Point3D' could use the instance variables, and another class e.g.
`Rectangle' coded in C could use the struct members. Use what is most
comfortable in a certain situation! That is Ruby's strength, I feel :-)

>  
>  -- gotoken
>  
>  # It is holiday `the sea day' in Japan but I don't know the meaning of
>  # today..

Interesting, but I also don't know! ;-)

\cle