[#8566] Visions for 2001/1.7.x development? — Robert Feldt <feldt@...>

Hi matz and other Ruby developers,

18 messages 2001/01/03
[#8645] Re: Visions for 2001/1.7.x development? — matz@... (Yukihiro Matsumoto) 2001/01/04

Hi,

[#8580] bug?? — jmichel@... (Jean Michel)

I don't understand the following behaviour:

19 messages 2001/01/03

[#8633] Interesting Language performance comparisons - Ruby, OCAML etc — "g forever" <g24ever@...>

13 messages 2001/01/04

[#8774] No :<, :>, etc. methods for Array — "Brian F. Feldman" <green@...>

So, why not include Comparable in Array by default? It shouldn't have any

28 messages 2001/01/07
[#8779] Re: No :<, :>, etc. methods for Array — matz@... (Yukihiro Matsumoto) 2001/01/07

Hi,

[#8780] Re: No :<, :>, etc. methods for Array — "Brian F. Feldman" <green@...> 2001/01/07

matz@zetabits.com (Yukihiro Matsumoto) wrote:

[#8781] Re: No :<, :>, etc. methods for Array — gotoken@... (GOTO Kentaro) 2001/01/07

In message "[ruby-talk:8780] Re: No :<, :>, etc. methods for Array"

[#8782] Re: No :<, :>, etc. methods for Array — "Brian F. Feldman" <green@...> 2001/01/07

gotoken@math.sci.hokudai.ac.jp (GOTO Kentaro) wrote:

[#8829] Sandbox (again) — wys@... (Clemens Wyss)

Hi,

20 messages 2001/01/08
[#8864] Re: Sandbox (again) — Clemens Hintze <c.hintze@...> 2001/01/08

On 8 Jan, Clemens Wyss wrote:

[#8931] String confusion — Anders Bengtsson <ndrsbngtssn@...>

Hello everyone,

21 messages 2001/01/09
[#8937] Re: String confusion — matz@... (Yukihiro Matsumoto) 2001/01/09

Hi,

[#8953] Please remove account from files — "Thomas Daniels" <westernporter@...>

Please take my e-mail address from your files and "CANCEL" my =

14 messages 2001/01/09
[#8983] Re: Please remove account from files — John Rubinubi <rubinubi@...> 2001/01/10

On Wed, 10 Jan 2001, Thomas Daniels wrote:

[#9020] time to divide -talk? (was: Please remove account from files) — Yasushi Shoji <yashi@...> 2001/01/10

At Wed, 10 Jan 2001 14:23:30 +0900,

[#9047] Re: time to divide -talk? (was: Please remov e account from files) — Aleksi Niemel<aleksi.niemela@...>

Yasushi Shoji:

27 messages 2001/01/10
[#9049] Re: time to divide -talk? — Yasushi Shoji <yashi@...> 2001/01/10

At Thu, 11 Jan 2001 00:20:45 +0900,

[#9153] what about this begin? — Anders Strandl Elkj誡 <ase@...> 2001/01/11

[#9195] Re: Redefining singleton methods — ts <decoux@...>

>>>>> "H" == Horst Duch=EAne?= <iso-8859-1> writes:

10 messages 2001/01/12

[#9242] polymorphism — Maurice Szmurlo <maurice@...>

hello

73 messages 2001/01/13

[#9279] Can ruby replace php? — Jim Freeze <jim@...>

When I read that ruby could be used to replace PHP I got really

15 messages 2001/01/14

[#9411] The Ruby Way — "Conrad Schneiker" <schneiker@...>

As a member of the "Big 8" newsgroups, "The Ruby Way" (of posting) is to

15 messages 2001/01/17

[#9462] Re: reading an entire file as a string — ts <decoux@...>

>>>>> "R" == Raja S <raja@cs.indiana.edu> writes:

35 messages 2001/01/17
[#9465] Re: reading an entire file as a string — Dave Thomas <Dave@...> 2001/01/17

raja@cs.indiana.edu (Raja S.) writes:

[#9521] Larry Wall INterview — ianm74@...

Larry was interviewed at the Perl/Ruby conference in Koyoto:

20 messages 2001/01/18
[#10583] Re: Larry Wall INterview — "greg strockbine" <gstrock@...> 2001/02/08

Larry Wall's interview is how I found out

[#9610] Re: 101 Misconceptions About Dynamic Languages — "Ben Tilly" <ben_tilly@...>

"Christian" <christians@syd.microforte.com.au> wrote:

13 messages 2001/01/20

[#9761] Re: 101 Misconceptions About Dynamic Languages — ts <decoux@...>

>>>>> "C" == Christoph Rippel <crippel@primenet.com> writes:

16 messages 2001/01/23

[#9792] Ruby 162 installer available — Dave Thomas <Dave@...>

15 messages 2001/01/24

[#9958] Re: Vim syntax files again. — "Conrad Schneiker" <schneik@...>

Hugh Sasse wrote:

14 messages 2001/01/26
[#10065] Re: Vim syntax files again. — Hugh Sasse Staff Elec Eng <hgs@...> 2001/01/29

On Sat, 27 Jan 2001, Conrad Schneiker wrote:

[#9975] line continuation — "David Ruby" <ruby_david@...>

can a ruby statement break into multiple lines?

18 messages 2001/01/27
[#9976] Re: line continuation — Michael Neumann <neumann@...> 2001/01/27

On Sat, 27 Jan 2001, David Ruby wrote:

[#9988] Re: line continuation — harryo@... (Harry Ohlsen) 2001/01/28

>A statement break into mutliple lines if it is not complete,

[ruby-talk:10015] Re: line continuation

From: Aleksi Niemel<zak@...>
Date: 2001-01-28 11:15:11 UTC
List: ruby-talk #10015
On Sun, 28 Jan 2001, Brian F. Feldman wrote:

> <ale@crimson.propagation.net> wrote:
> > Anyway, this bug doesn't bite too often by accident. If you adopt
> > "right" style to write code (include operator or dot as a hint of
> > continuation to the same line) it's very rare event you need
> > '\'. During my sufficiently short Ruby career I can't remember using
> > this notation more than two times.
> > 
> > Usually when a statement grows over line there's something in your
> > code which uses it's last way of signalling it should be fixed.
> 
> I disagree with that, since it is in the style of functional programming to 
> have a large "chain" of methods acting upon a series of lists (or, in Ruby's 
> case, Arrays).  For example:
> 
>     def CDDB.from_sql(res)
>         unsubber = lambda {|s|
>             s.scan(/[^\\]("([^"\\]|\\.)*")/).
>               collect {|e| e[0][1..-2].gsub(/\\(.)/, '\1')}
>         }
>         CDDBStruct.new(unsubber.call(res[0]), res[1], unsubber.call(res[2]),
>           res[3], unsubber.call(res[4]),
>           res[5][1..-2].split(',').collect {|x| x.to_i})
>     end
> 
> You'll probably see even longer chains than that all the time, and in those 
> cases I think that when a statement is more than a line because of this, 
> it's specifically doing things right!

While I agree with you that there's a certain tendency to produce
chains of calls, I have to keep staying behind my opinion. My very
argument against this style of coding is the fact that it's painful to
read above code, and even more painful to change it.

I like call chaining, even to the point I really like to get away with
most method! anomalities (returning nil sometimes; actually I fixed
one of these from someone else's code which didn't work for me).

Simultaneously when you reorganize the above code there's an effect
that you give name to a thing you handle; be it a command chain,
a parameter or a helper variable.

     def CDDB.from_sql(res)
         quoted_string_re = /[^\\]("([^"\\]|\\.)*")/
         unsubber = lambda do |s|
             s.scan(quoted_string_re).collect do |e| 
                 e[0][1..-2].gsub(/\\(.)/, '\1')}
             end
         end
         listed_numbers = res[5][1..-2].split(',').collect {|x| x.to_i}
         CDDBStruct.new(unsubber.call(res[0]), res[1],
                        unsubber.call(res[2]), res[3], 
                        unsubber.call(res[4]), listed_numbers)
     end

I'm not claiming this example is in some way the ultimate, most
readable version, but I find my version easier to read and mess
around.

Still I'd like to exploit the possible rule of "unsub every second
parameter", name the mystical range of 1..-2, give better names to
variables in unsubber, maybe split the long line of listed_numbers
definition into two lines and call collect! on the latter.

Anyway, I guess you get my point. I think it's quite rare event that
you really have to have over 75 character (or some limit) lines. I
hear the exceeding line length as a cry requesting some code massage.

There are some simple cases where the change is easy to do, like
spreading inlined blocks to multiple lines ({..} notation to do..end),
and with parameter passing I feel no guilty having couple of lines
between opposing parentheses (as long as the content doesn't contain
too much of executed code).

Do we still disagree ?)

    - Aleksi

In This Thread