Re: Literal inconsistency

On Tue, 5 Sep 2006, Calamitas wrote:

> But whatever the reason for the optimization, it unexpectedly broke some 
> code of mine. Sometimes I wonder if it might be interesting to have a 
> list of optimizations in Ruby that are (usually unexpectedly) visible to 
> the programmer and that programmers may want to beware of.

a lot unexpectedly broke lately, which I all fixed today in my code... 
here's the list of stuff I fixed in my library for today:

1. can't use ->len and ->ptr in Arrays anymore
1. can't use ->len and ->ptr in Strings anymore
3. can't use T_SYMBOL anymore (merged with T_STRING)
4. strings returned from Kernel#instance_methods are now read-only

i had already abstracted out most uses of ->len and ->ptr as rb_ary_len, 
rb_ary_ptr, etc. since 2002 or so; so I just had to #ifdef it, as well as 
redef T_SYMBOL. May anyone confirm that the following patch to my code 
makes sense?

#ifdef RARRAY_LEN
#undef T_SYMBOL
#define T_SYMBOL T_STRING
static inline long  rb_str_len(Ruby s) {return RSTRING_LEN(s);}
static inline char *rb_str_ptr(Ruby s) {return RSTRING_PTR(s);}
static inline long  rb_ary_len(Ruby s) {return  RARRAY_LEN(s);}
static inline Ruby *rb_ary_ptr(Ruby s) {return  RARRAY_PTR(s);}
#else
static inline long  rb_str_len(Ruby s) {return RSTRING(s)->len;}
static inline char *rb_str_ptr(Ruby s) {return RSTRING(s)->ptr;}
static inline long  rb_ary_len(Ruby s) {return  RARRAY(s)->len;}
static inline Ruby *rb_ary_ptr(Ruby s) {return  RARRAY(s)->ptr;}
#endif

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - t駘:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montr饌l QC Canada