< :the previous in number
^ :the list in numerical order
> :the next in number
P :the previous artilce (have the same parent)
N :the next artilce (have the same parent)
|<: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
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