[#33640] [Ruby 1.9-Bug#4136][Open] Enumerable#reject should not inherit the receiver's instance variables — Hiro Asari <redmine@...>

Bug #4136: Enumerable#reject should not inherit the receiver's instance variables

10 messages 2010/12/08

[#33667] [Ruby 1.9-Bug#4149][Open] Documentation submission: syslog standard library — mathew murphy <redmine@...>

Bug #4149: Documentation submission: syslog standard library

11 messages 2010/12/10

[#33683] [feature:trunk] Enumerable#categorize — Tanaka Akira <akr@...>

Hi.

14 messages 2010/12/12
[#33684] Re: [feature:trunk] Enumerable#categorize — "Martin J. Dst" <duerst@...> 2010/12/12

[#33687] Towards a standardized AST for Ruby code — Magnus Holm <judofyr@...>

Hey folks,

23 messages 2010/12/12
[#33688] Re: Towards a standardized AST for Ruby code — Charles Oliver Nutter <headius@...> 2010/12/12

On Sun, Dec 12, 2010 at 9:55 AM, Magnus Holm <judofyr@gmail.com> wrote:

[#33689] Re: Towards a standardized AST for Ruby code — "Haase, Konstantin" <Konstantin.Haase@...> 2010/12/12

On Dec 12, 2010, at 17:46 , Charles Oliver Nutter wrote:

[#33763] [Ruby 1.9-Bug#4168][Open] WeakRef is unsafe to use in Ruby 1.9 — Brian Durand <redmine@...>

Bug #4168: WeakRef is unsafe to use in Ruby 1.9

43 messages 2010/12/17

[#33815] trunk warnflags build issue with curb 0.7.9? — Jon <jon.forums@...>

As this may turn out to be a 3rd party issue rather than a bug, I'd like some feedback.

11 messages 2010/12/22

[#33833] Ruby 1.9.2 is going to be released — "Yuki Sonoda (Yugui)" <yugui@...>

-----BEGIN PGP SIGNED MESSAGE-----

15 messages 2010/12/23

[#33846] [Ruby 1.9-Feature#4197][Open] Improvement of the benchmark library — Benoit Daloze <redmine@...>

Feature #4197: Improvement of the benchmark library

15 messages 2010/12/23

[#33910] [Ruby 1.9-Feature#4211][Open] Converting the Ruby and C API documentation to YARD syntax — Loren Segal <redmine@...>

Feature #4211: Converting the Ruby and C API documentation to YARD syntax

10 messages 2010/12/26

[#33923] [Ruby 1.9-Bug#4214][Open] Fiddle::WINDOWS == false on Windows — Jon Forums <redmine@...>

Bug #4214: Fiddle::WINDOWS == false on Windows

15 messages 2010/12/27

[ruby-core:34018] Re: Multi-line comments

From: mathew <meta@...>
Date: 2010-12-31 15:57:40 UTC
List: ruby-core #34018
On Mon, Dec 27, 2010 at 19:55, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com> wrote:
> Please, could someone explain me why supporting multi-line comments
> is a bad thing?

As soon as you allow multi-line comments, you need to decide what to
do about nested multi-line comments, i.e. the 'start comment' sequence
inside a comment.

Option 1 is to allow it and make it not special. This is bad because
it makes it very easy to end up with a run-away comment:

    /* set variables
    param = 0
    /* set maximum size */
    maxs = 100

Here 'param' ends up unset. This kind of bug can be really hard to locate.

Option 2 is to allow the start-comment sequence within a comment, and
make comment pairs stack, so you need as many end-comment sequences as
start-comment sequences. This at least makes errors like the above
cause a compile-time failure, but it still makes them a pain to
locate; you end up having to use something like vim's '%' command to
play match-the-comment-delimiters until you spot which pair is
mismatched. That's no fun, especially once your comments contain pages
of documentation. Ask a Java programmer...

Option 3 is to disallow nested comments, in which case multi-line
comments can't be used to comment out blocks of code which contain
multi-line comments. That makes them pretty useless for temporary
disabling of code; it would also cripple their use in rdoc.

Single-line comments have none of the above problems. You always know
the comment will end when the next line starts. You can always comment
out a block of code, no matter how many comments or
comments-within-comments it contains. You never get runaway comments,
you never have to match up comment delimiters.

The only downside to single-line comments is that it's harder to
comment out and un-comment-out multiple lines. That's easily solved by
using any good text editor.

All of which is why C++ introduced single-line comments, and C99 added
them to regular C.

So in short, multi-line comments have no significant advantages, make
parsing harder, and make errors more likely. I think Matz was entirely
right not to put them in Ruby.

As a rule, the only place I use multi-line comments is for JavaDoc,
and that's only because I have to.


mathew
-- 
<URL:http://www.pobox.com/~meta/>

In This Thread