< :the previous in number
^ :the list in numerical order
> :the next in number
P :the previous artilce (have the same parent)
N :the next (in thread)
|<:the top of this thread
>|:the next thread
^ :the parent (reply-to)
_:the child (an article replying to this)
>:the elder article having the same parent
<:the youger article having the same parent
---:split window and show thread lists
| :split window (vertically) and show thread lists
~ :close the thread frame
.:the index
..:the index of indices
Hi, Aleksi,
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/9096
> From: Aleksi Niemel
> Sent: Tuesday, July 04, 2000 10:23 PM
> These and your example was exactly what I was looking for! Thank you.
You are welcome.
> Now I've come up with another proposition. We could change the behaviour in
> next versions. (And of course provide a simple, yet most cases fixing
> upgrade script.) We could define obj.method! to *always* return the
> possibly altered object.
Yes, we can change the behaviour in future versions.
> And, now the new trick, add Array.uniq!? which would work like current
> Array.uniq!. The actual semantic hint the developer should get when he sees
> obj.method!? is 'this method modifies the object and returns something
> (possibly boolean) describing if any action was taken'.
Your proposition recalled me an old article in ruby-list...yes,
I found it.
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/9096
We Japanese users discussed this issue, but we could not come to
a conclusion. I cannot find any objection now. Matz, how do you
think this proposition?
Aleksi, how do you think 'String#gsub?'. Seeing 'String#gsub?',
how do people think?
// NaHi