From: Daniel Brockman <daniel@...>
Date: 2005-07-20T10:23:01+09:00
Subject: Re: `not' in parameter lists

Hi Devin,

> I find (method *arguments) more readable than
> method(*arguments) though, especially in a nest of stuff.

That's interesting...  Are you a long-time Lisper?

>>   (case
>>     (when (bar.respond-to? :moomin)
>>       (puts "snufkin")
>>     (else
>>       (something-or-other))
>
> I dunno. Unnecessary parens, IMO. Also, I don't like
> putting a close paren/closing tag/end keyword at the end
> of a line unless the open paren/open tag/begin keyword is
> at the beginning of the same line. That way it's easier to
> spot code that's missing an end-tag.

...nope, definitely not a Lisper. :-)

(Yes, I do appreciate the irony of the fact that I missed,
not one, but *two* parens in the above snippet of code.)

> (And you can't give up the end-tag unless you want
> significant whitespace.)

With the risk of being denounced for a heretic, I have to
say that I wouldn't mind a flag that turned this on. :-)

I'm not particularly fond of the ‘end’ ladders, although I
do appreciate them when reading or writing code without
syntax highlighting and all the other editor features you
take for granted (like on a maling list).

> Joel Spolsky has a decent piece on making wrong code
> *look* wrong.

...I don't see the point.  Won't this do?

   # THIS CODE IS BROKEN AND WRONG --- DO NOT USE
   # UNDER ANY CIRCUMSTANCES!

> Of course, in it, he advocates Hungarian notation, but one
> can look past that to see the meat of the article... :)

I guess I'll have to dig it up.  I do recall reading
something where he advocates Hungarian notation, but he
probably does that all the time.  I guess you can't really
blame him though; after all, he's been exposed to God knows
how much of Microsoft's C code.

>> Therefore, I think the parentheses of a last-parameter
>> nested method call should be optional, analogously to the
>> implicit hash syntax.
>
> OK, for what it's worth, I like.

What do other people think?  [For those of you who didn't
follow this thread, we're talking about allowing this

   assert foo.respond_to? :bar

and this (excuse the brain-dead example)
   
   assert foo == bar, "foo!@# differs from bar".delete "!@#"

but not this,

   assert foo.respond_to? :bar, "foo doesn't respond to :bar"

because of the ambiguity.]

>> Maybe you'd be interested in a preprocessor[2] that lets
>> you use hyphens instead of underscores?
>
> Yeek. Preprocessors = evil! Granted, this one's written in
> plain Ruby, which is neat, but still.

I hear there's an independent “exprerimental” branch of Ruby
out there; I've been thinking about trying to get some of
this stuff into that... maybe as a kind of stepping stone.

> If I could just say require 'hyphen-ruby' and not __END__
> at the beginning of the code...

Aw, come on.  You don't even need the __END__ in any other
files apart from the one that contains the main entry point.
Actually, if you write that file in vanilla Ruby, you don't
need to put __END__ *anywhere*. :-)

>>   @timers.each { .fire if .ready? }
>
> That's neat.

I'm glad you like it. :-)

> Devin
> eat_program. hehe...

Hey, you gotta have a system metaphor.  Mine is a cookie
monster that eats text instead of cookies. :-)

-- 
Daniel Brockman <daniel@brockman.se>

    So really, we all have to ask ourselves:
    Am I waiting for RMS to do this?   --TTN.