From: Laurent Sansonetti <laurent.sansonetti@...>
Date: 2008-03-16T03:15:52+09:00
Subject: Re: RARRAY_PTR

On Sat, Mar 15, 2008 at 6:42 AM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> Hi,
>
>  In message "Re: RARRAY_PTR"
>
>     on Sat, 15 Mar 2008 09:40:15 +0900, "Laurent Sansonetti" <laurent.sansonetti@gmail.com> writes:
>
>  |Currently, ruby.h defines RARRAY_PTR as a macro to access the internal
>  |C array of the RArray structure (which represents the Array class).
>  |This macro is used in many places in the Ruby code (and extensions) to
>  |get an element at a particular index
>  |
>  |  VALUE v = RARRAY_PTR(ary)[42];
>  |
>  |But some people also use it to set values
>  |
>  |  RARRAY_PTR(ary)[0] = Qnil;
>  |
>  |I think this macro is dangerous because it exposes too much internals.
>  |Also, it is difficult to re-implement RArray using a different storage
>  |structure and efficiently support this macro at the same time. In
>  |MacRuby I am working on a new implementation of the Array class and
>  |will not be able to support this macro for inline modifications.
>
>  How about officially declaring RARRAY_PTR() is read-only?  In fact, it
>  IS read-only.
>

I have been thinking about this, RARRAY_PTR could return a const
value. Right now it doesn't seem to.

But there is still the problem of accessing elements in the array.
People use RARRAY_PTR(ary)[idx] for that. Nobu-san's RARRAY_AT macro
idea is good because it doesn't expose the underlying implementation
of the class (and it can also do a boundary check).

If the genuine Ruby in the future wants to re-implement RArray using a
different storage structure, the interface would already be there.

# If you desire I can work on a patch.

Laurent