From: Ben Giddings <bg-rubytalk@...>
Date: 2004-08-04T09:15:25+09:00
Subject: Re: Macros in Ruby

Jesse Jones wrote:
> For example, suppose you're writing a game and you have a lot of code
> that selects behavior based on percentages (75% of hits are normal
> blows, 20% are critical hits, and 5% kill your foe out-right for
> example). Even in a language as expressive as Ruby this is a bit
> awkward to write and not especially intentional. But with macros it can
> be written very cleanly:
> 
> percent-case
>    0.75 case
>       normal_hit
>    end
> 
>    0.20 case
>       critical_hit
>    end
> 
>    otherwise
>       kill_foe
>    end
> end

I'm sorry to say it, but I think you just proved Matz' point there.  I 
look at that, and it doesn't look like Ruby to me.  Even with your 
explanation, I don't understand how it works, or how to modify it.  Is 
"case" in your code the normal ruby "case" statement?  It doesn't look 
like it.

The one place I've really missed macros is in debugging.  I'm really 
used to C macros that are really simple to type 'dbg(val);' but can 
produce detailed valuable output:

foo.c:132 do_it() val => 23

There are hackish ways to get something approaching this in Ruby, mainly 
by twiddling with the 'caller' array, and using symbols to grab the name 
of the symbol along with its value.  That feels really hackish to me. 
I'd feel slightly better about it if callers returned an array of 
"SourceLine" objects, or something, and you could get the method name as 
well.  But it's still not quite up there with the ease of use of a C macro.

On the other hand, aside for this and a few other isolated cases, I 
*hate* C macros, and *hate* the C preprocessor.  It means that when 
you're writing .c and .h files, you're not actually writing C code, 
you're writing C/C-preprocessor code, and depending on who has touched 
the codebase, you never quite know what's what.

I don't know if there's a middle ground, but I certainly lean towards 
avoiding macros.

Ben