[#2332] Ruby-Python fusion? — mrilu <mrilu@...>
Usually I give some time for news to settle before I pass the word, but
7 messages
2000/04/01
[#2353] Re: Function of Array.filter surprises me — schneik@...
5 messages
2000/04/03
[#2361] crontab — Hugh Sasse Staff Elec Eng <hgs@...>
I want to have a program that may be run between certain times.
11 messages
2000/04/05
[#2375] Marshal: Want string out, but want depth specified? — Hugh Sasse Staff Elec Eng <hgs@...>
@encoded = [Marshal.dump(@decoded, , depth)].pack("m")
7 messages
2000/04/07
[#2378] Re: Marshal: Want string out, but want depth specified?
— matz@... (Yukihiro Matsumoto)
2000/04/07
Hi,
[#2376] Iterator into array — Dave Thomas <Dave@...>
15 messages
2000/04/07
[#2397] Could missing 'end' be reported better? — mrilu <mrilu@...>
I'm not sure one could easily parse, or moreover report, this error better.
5 messages
2000/04/08
[#2404] Re: Iterator into array — Andrew Hunt <andy@...>
>It's still possible to introduce a new syntax for collecting yielded
6 messages
2000/04/08
[#2412] Re: Could missing 'end' be reported better? — h.fulton@...
7 messages
2000/04/09
[#2414] Re: Could missing 'end' be reported better?
— matz@... (Yukihiro Matsumoto)
2000/04/09
Hi,
[#2429] Please join me, I'm Hashing documentation — mrilu <mrilu@...>
This is a story about my hashing ventures, try to bear with me.
5 messages
2000/04/10
[#2459] Precedence question — Dave Thomas <Dave@...>
7 messages
2000/04/12
[#2474] Ruby 1.4.4 — Yukihiro Matsumoto <matz@...>
Ruby 1.4.4 is out, check out:
5 messages
2000/04/14
[#2494] ANNOUNCE : PL/Ruby — ts <decoux@...>
7 messages
2000/04/17
[#2495] Re: 'in' vs. 'into' — Andrew Hunt <andy@...>
># rescue MyException into myVar
4 messages
2000/04/17
[#2514] frozen behavior — Andrew Hunt <Andy@...>
7 messages
2000/04/19
[#2530] Re: 'in' vs. 'into' — Andrew Hunt <andy@...>
>Hmm, I've not decided yet. Here's the list of options:
6 messages
2000/04/20
[#2535] Default naming for iterator parameters — mrilu <mrilu@...>
I'm back at my computer after some traveling. I know I think Ruby
5 messages
2000/04/20
[#2598] different thread semantics 1.4.3 -> 1.4.4 — hipster <hipster@...4all.nl>
Hi fellow rubies,
4 messages
2000/04/28
[ruby-talk:02558] Re: Default naming for iterator parameters
From:
mrilu <mrilu@...>
Date:
2000-04-21 16:43:55 UTC
List:
ruby-talk #2558
On Fri, 21 Apr 2000, Yukihiro Matsumoto wrote:
> In message "[ruby-talk:02535] Default naming for iterator parameters"
> on 00/04/20, mrilu <mrilu@ale.cx> writes:
>
> |{'foo' => 'bar', 'dog' => 'bert'}.each_pair {
> | |key, value|
> | print key, ": ", value, "\n"
> |}
> |I thought being able to set default iterator parameter naming *might*
> |be good idea.
Now, there seems to be basically two arguments against default variable
names.
The first,
Matz:
> Hmm, I'm too lazy to learn magic variable names for each methods.
Quinn, Andy:
>The lazy part of my brain (which is also sizable) does not like the idea. It
>objects to having to learn the "magic" words for each iterator I use. This
I think these are basically the same thing and I can't agree. The more I
think about this the more convinced I am that as a user of an iterator
short hand form could make things easier (or lazier :). And if needed you
can use the long form anyway.
My point is based mostly on the fact in the beginning I have to skim
through the docs all the time reading foo.each{ |index| } or something.
After a while I begin to remember the iterator signatures and I'm able
to write code without lookups. At that point I recall for this iterator
there's only one variable which role is index. If I want to rename it,
it goes like now but if the role is a good name, which I think is the
case usually (that is with small iterators) why bother to write it again.
So, there's the second point:
>reading other people's code: "where'd *that* variable come from? hmm, not up
>here, not over here, oh it maybe it's one of those magic parameters, where's
>the documentation for this iterator? well, it's coming from the object `foo',
>so what class is `foo'? *page page* aha, looks like it's a Bar, or maybe a
>subclass. well, there is no doc for Bar#iterator, but aha, the Baz mix-in
>does have iterator! ok, now where was I?"
This could be very true. We might lose some readibility. I don't have so much
experience of the world of Ruby iterators to be able to judge whether
one can associate iterators variables at once or it will cause confusion.
I bet on confusion on longer iterators, but then I could ask was it good idea
in the first place to write such code? Not to name the non-obvious, or hide the
code flow under massive pile of code? Here I need some help
from veteranes? Do you write
foo.bar {
zaq = prepare_for_big_code(foo)
too_big_block_to_write_directly(zaq, bar)
}
Quinn:
>the same time. I gave up on perl because of too much thrashing between code
>and the man pages.
I agree. And Perl coders necessary man page usage hit the spot too. It's
easy to generate unnecessary details. But somehow it's easier for me
to understand
array.each{ print element }
than
array.each{ |element| print element }
The latter case is not trashing on my brain, but surely paging for
because of "unnecessary" variable declaration :).
One small point.
> What would you propose if the there were already local variables
> that had the same name as the default ones?
I can't see this to be problem at all (like somebody else agreed too),
since you're always able to (re)name iterator variables.
And one last and small point.
{'foo' => 'bar', 'dog' => 'bert'}.each_pair {
# |key, value|
print key, ": ", value, "\n"
}
The version without |declaration| is better prepared for change of
parameter passing. If we suddenly want to change the call to |value,key|
the above code needs no change :).