[#2617] irb for 1.5.x — Andrew Hunt <Andy@...>
5 messages
2000/05/03
[#2639] OT: Japanese names — Dave Thomas <Dave@...>
4 messages
2000/05/09
[#2643] Ruby Toplevel — Dave Thomas <Dave@...>
7 messages
2000/05/09
[#2656] Re: Append alias for Array.append? — Aleksi Niemel<aleksi.niemela@...>
Hideto ISHIBASHI:
5 messages
2000/05/09
[#2660] win OLE / eRuby — Andrew Hunt <Andy@...>
8 messages
2000/05/09
[#2663] Re: win OLE / eRuby — Aleksi Niemel<aleksi.niemela@...>
>At Tue, 9 May 2000 09:14:51 -0400,
4 messages
2000/05/09
[#2667] The reference manual is now online — Dave Thomas <Dave@...>
6 messages
2000/05/09
[#2668] Re: The reference manual is now online — schneik@...
4 messages
2000/05/09
[#2685] Re: Tainting — ts <decoux@...>
>>>>> "D" == Dave Thomas <Dave@thomases.com> writes:
6 messages
2000/05/10
[#2702] Re: Append alias for Array.append? — Andrew Hunt <andy@...>
>From: Aleksi Niemel<aleksi.niemela@cinnober.com>
7 messages
2000/05/10
[#2752] RE: Array.pop and documentation [was: Append al ias for Array.append?] — Aleksi Niemel<aleksi.niemela@...>
6 messages
2000/05/11
[#2758] Re: irb install — Andrew Hunt <andy@...>
>|Excellent! Will you consider adding mod_ruby to install_app as
7 messages
2000/05/11
[#2777] Re: irb install
— "NAKAMURA, Hiroshi" <nakahiro@...>
2000/05/12
Hi,
[#2764] More code browsing questions — Albert Wagner <alwagner@...>
I see some class definitions contain "include" and "extend" statements.
6 messages
2000/05/12
[#2793] After-the-fact installation questions — Albert Wagner <alwagner@...>
I probably should have asked this before I installed. I unpacked
4 messages
2000/05/12
[#2843] Re: editors for ruby — "Conrad Schneiker" <schneiker@...>
(Posted on comp.lang.ruby and ruby-talk ML.)
6 messages
2000/05/17
[#2874] RE: simple httpd for local use — Aleksi Niemel<aleksi.niemela@...>
> I personally use it for access to full-text indexed linux
6 messages
2000/05/18
[#2875] Re: simple httpd for local use
— hipster <hipster@...4all.nl>
2000/05/18
On Thu, 18 May 2000 09:10:28 +0200, Aleksi Niemelwrote:
[#2920] SWIG: virtual variable? — Yasushi Shoji <yashi@...>
hello,
4 messages
2000/05/22
[#2928] FYI: What our Python friends are up to. — "Conrad Schneiker" <schneiker@...>
Hi,
8 messages
2000/05/22
[#2964] Thank you — h.fulton@...
Thanks, Matz (and others) for your replies to
4 messages
2000/05/24
[#2973] Re: Socket.getnameinfo — ts <decoux@...>
>>>>> "D" == Dave Thomas <Dave@thomases.com> writes:
10 messages
2000/05/25
[#3016] rbconfig.rb — Dave Thomas <Dave@...>
5 messages
2000/05/28
[#3039] Re: Final for World Series: Python vs Ruby — "Dat Nguyen" <thucdat@...>
1 message
2000/05/30
[#3058] FailureClass? — Aleksi Niemel<aleksi.niemela@...>
Question arising from the FAQ:
7 messages
2000/05/31
[ruby-talk:02805] Re: Array.pop and documentation [was: Append alias for Array.append?]
From:
"Conrad Schneiker" <schneiker@...>
Date:
2000-05-13 07:02:54 UTC
List:
ruby-talk #2805
Hi,
From: Albert
> For readability you can't beat Smalltalk:
>
> anArray.sliceFromPos: int forLengthOf: int # now that's a readable
> signature, or
> aDictionary.atKey: var putValue: var
Sort of looks like COBOL done right and made worth keeping around.
> For readability you are already limited by function syntax: name(arg1,
> arg2, ...).
> If readability is a high priority then the best you can do with function
> syntax is keyword args. You have noticed how, when reading new code
> such as:
>
> functionName("Once...", 13, name, ':', name, name)
>
> You can't tell a thing about what is happening without looking at the
> code of functionName and examining what happens to each arg.
Well readability is a high priority up to a point. So is convenience. So is
simplicity. So is synergy. So is naturalness. And these all involve tricky
trade-offs, which precludes any sort of mono-dimensional priority. Well
known standard functions with 0 or 1 parameters are simple, readable, and
convenient and so are nice to have, even though reading new code with
user-defined many-parameter functions is (often) troublesome, as you noted.
As for "truncate" in place of "slice", I prefer the more terse "chop",
giving:
chop_start
chop_start(n)
chop(m,n)
chop_end(n)
chop_end
Conrad