'Special' method highlighting - a list

Doug Kearns djkea2 at mugca.its.monash.edu.au
Fri Aug 22 21:46:06 EDT 2003

On Fri, Aug 22, 2003 at 12:32:48AM +1000, Gavin Sinclair wrote:

> I've had a look at the "special" methods (those in Module, Class,
> Object and Kernel), and here is what I think should be highlighted, in
> addition to what we have now.
>   attr, attr_accessor, attr_reader, attr_writer
>   alias_method (?)
>   callcc
>   fork
>   public, private, protected
> My heuristic is as follows.  A "special" method, worthy of
> highlighting, is one which:
>  (a) is called without a receiver
>  (b) performs a magic trick not typically achievable in Ruby alone,
>      such that it is easily mistaken for genuine keyword

Sounds reasonable.
> Reason (a) excludes "new" and "exclude".  I think highlighting a
> method that has an explicit receiver is ugly.
> Reason (b) covers "callcc" and "fork", which seem magical enough to
> me.  Ditto "private" et al.  The "attr" family can be implemented
> in Ruby easily, but they are so commonly used as to be almost part of
> the language and come in for special mention.

Agreed, I certainly consider the attr* methods to be 'magic'.
> "alias_method" I put in because "alias" is highlighted.  Then again,
> that goes for "undef_method" as well.  I am unsure about that one.  I
> always just use "alias" anyway. 

A quick grep of my ruby directory finds about 2500 uses of alias and
only about 100 of alias_method. 20 for undef and about 10 for
undef_method. As such I'd leave out undef_method and alias_method, I
think they may be the top of the 'slippery slope'.

> I wish Ruby could lose some of this clutter, like "attr".  I mean,
> really...

> Anyway, discussion is welcomed on these items, especially the "attr"
> family and "alias_method", which can be argued either way.  The others
> are clear cut in my mind.

Some others might include:

  exit|abort -> at_exit(?)
  eval       -> {module,instance,class}_eval(?)

More information about the vim-ruby-devel mailing list