On 10/13/06, Kevin Olemoh <darkintent / gmail.com> wrote:
> The Firefox developers have been busy for about five years telling
> people that there should not be an interface to change keybindings.
> The gnome developers have been telling people that they don't need
> various options for some time as well and they are definetly not right
> on alot of those issues. Opera software has had ages to implement  an
> extension system yet they do little if anything at all while people
> say that Opera does not need a robust extension system like the one in
> Firefox (completely ignoring reality) Just because some "heavy" weight
> says one thing does not make it right.

It wasn't just said: it was explained. Why does Firefox need an
interface (I presume you mean GUI) to change keybindings? What
*possible* value does it provide that isn't countered by the massive
headache it would introduce? While I think that the GNOME developers
have hidden *too much*, I think that it's better to by default hide
things that don't matter to 99% of the people out there.

Compare it to Rails. Close to 90% of the decisions about the structure
of your application are made *for* you by Rails. Sure, you can override
it, but you have to go out of your way to do so. I disagree with a lot
of the choices that the Rails core team has made, but I can't argue with
the speed with which I've developed the application I have been using
for my wedding guest list management.

> My whole point is that the interpereter should not have syntactic
> rules that end up creating formatting requirements.  As someone else
> pointed out those two are indeed different so the question is really
> "Should block parameters break because of a newline before '{' ?"  The
> fact that {} is a parameter is not really even relevant to my request.
> It just gives me insight into why the problem exists in the first
> place.

I see your problem here, Kevin. You're not understanding Ruby.

    # This method takes a block. It just doesn't do anything with it.
    def foo
    end
    foo {|| puts "ha!" }

    # This method also takes a block. It does something with it.
    def bar
      yield
    end
    bar {|| puts "ha!" }

    # This method *also* takes a block, and turns it into a formal
    # parameter. It doesn't do anything with it.
    def baz(&block)
    end
    baz {|| puts "ha!" }

    # This method *also* takes a block, and turns it into a formal
    # parameter. It does something with it.
    def quux(&block)
        block.call
    end
    quux {|| puts "ha!" }

    # This method takes a block as a formal parameter only.
    def qix(block)
      raise unless block.kind_of?(Proc)
      block.call
    end
    qix(lambda {|| puts "ha!" })

A block is not a parameter. You can *make* it a parameter, as shown
above, but by default, it's something that's implicit. So, it isn't even
remotely close to what you thought it was.

If you still think it can be fixed and is worth fixing, please -- try to
patch the code.

-austin
-- 
Austin Ziegler * halostatue / gmail.com * http://www.halostatue.ca/
               * austin / halostatue.ca * http://www.halostatue.ca/feed/
               * austin / zieglers.ca