[#1026] Is this a bug? — Dave Thomas <Dave@...>
18 messages
2000/01/03
[#1053] rand() / drand48() — ts <decoux@...>
11 messages
2000/01/05
[#1055] Re: rand() / drand48()
— matz@... (Yukihiro Matsumoto)
2000/01/05
[#1061] Re: rand() / drand48()
— gotoken@... (GOTO Kentaro)
2000/01/07
Hi,
[#1067] Here docs not skipping leading spaces — Dave Thomas <Dave@...>
5 messages
2000/01/08
[#1083] YADQ (Yet Another Dumb Question) — Dave Thomas <Dave@...>
12 messages
2000/01/10
[#1084] Infinite loop — Dave Thomas <Dave@...>
17 messages
2000/01/11
[#1104] The value of while... — Dave Thomas <Dave@...>
24 messages
2000/01/11
[#1114] Re: The value of while...
— Dave Thomas <Dave@...>
2000/01/12
matz@netlab.co.jp (Yukihiro Matsumoto) writes:
[#1128] Re: The value of while... — David Suarez de Lis <excalibor@...>
Hi all,
1 message
2000/01/12
[#1133] Re: Class variables... — David Suarez de Lis <excalibor@...>
Hi there,
2 messages
2000/01/12
[#1158] Is this expected behavior? — Dave Thomas <Dave@...>
6 messages
2000/01/21
[#1172] Re: Possible bug in ruby-man-1.4 — Huayin Wang <wang@...>
> |Well, I guess it comes down to what you mean by an integer
10 messages
2000/01/24
[#1177] Re: Possible bug in ruby-man-1.4
— Dave Thomas <Dave@...>
2000/01/25
matz@netlab.co.jp (Yukihiro Matsumoto) writes:
[#1188] Enumerable and index — Dave Thomas <Dave@...>
5 messages
2000/01/27
[#1193] Semantics of chomp/chop — Dave Thomas <Dave@...>
7 messages
2000/01/28
[#1197] Question about 'open' — Dave Thomas <Dave@...>
8 messages
2000/01/30
[ruby-talk:01056] Re: ..
From:
matz@... (Yukihiro Matsumoto)
Date:
2000-01-05 18:35:58 UTC
List:
ruby-talk #1056
Hi,
In message "[ruby-talk:01054] .."
on 00/01/05, Dave Thomas <Dave@thomases.com> writes:
| If I override '..', is it true that I can only use it in functional
| form? The parser seems to have operator .. hard coded to be a Range.
Yes, and no.
* operator .. and ... are hard coded, so you can only call it by
using `send'. So answer should be yes for the current
interpreter.
* in reference manual, .. and ... are listed among non-redfinable
operators. But the parser treats .. operator (not ... operator)
as redfinable by accident. It is bug. It should not be able to
override. I'll fix it in next release. So answer shoule be no.
The reasons that range operators are hard coded to be a Range are:
* ../... operators appearing in conditionals, it is treated special,
just like ../... operators in scalar context in Perl. It cannot
be done by methods.
* since Range objects are immutable, range objects whose operands
are literals will be cached in the parse tree. It helps
perfomance because ranges appear a lot for array slicing etc.
Clemens suggested that ../... operators out of conditionals to call
../... methods, but I'm hesitating it for the latter reason.
matz.