'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:
<snip>
> 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:
autoload
exit|abort -> at_exit(?)
eval -> {module,instance,class}_eval(?)
caller(?)
Regards,
Doug
More information about the vim-ruby-devel
mailing list