It seems like semicolon insertion is an example of browsers being liberal acceptors of slop. Good that the rules are codified by ECMA, much like HTML5's error recovery parsing rules, but I wouldn't omit semicolons on purpose.
If action comes from outside the program, this can open up unexpected behavior. The dispatch table is closed - there's less chance that user input will invoke something unintended.
In a real world program you would validate input and make sure you get something callable (with either technique). The only additional unexpected behavior is when there could be unexpected handle_xxx attributes. If we take for granted that the programmer defines the dict for the explicit dispatch table, though, we can also assume that the programmer defines the object for the implicit table.
IMO as code gets modified by other developers, the table is easier to keep 'safe' since it is clearer that is what it's for, the sprintf and all the other methods don't tend to be in one place - as methods get added, the reflection issue is oft overlooked.
I feel the version from the original comment is most Pythonic. The other version is close to an eval-function, which seems to be frowned up on in Python.
The second version is slower too. Here's what I use for e.g. a state machine, which follows "don't repeat yourself" a little better than the first example:
# {state_name: state_action}
states = {}
state = ['start']
def reg(func):
states[func.__name__] = func
return func
# define and simultaneously register the states
@reg
def start():
state[0] = 'second'
@reg
def second():
state[0] = 'last'
@reg
def last():
state[0] = None
# run the state machine
while state[0]:
print state[0]
states[state[0]]()
Schematic tables [http://subtextual.org/OOPSLA07.pdf] are an extension of this idea that can handle arbitrarily complex conditionals. Unfortunately, they only work in Subtext [http://subtextual.org/], an unreleased research language. Schematic tables take advantage of the 2-dimensional visual layout of Subtext (as opposed to linear text, like most languages); it would be very interesting to see something similar in text.
> If you think for a moment how exactly non-standard fonts are used in the web design, it will immediately make perfect sense. They are used sparingly for headers, menus and such and they are always rasterized.
Non-standard fonts are used sparingly precisely because they have to be rasterized.
He is talking about the state of affairs and how that creates an immediate opportunity for type designers willing to sell rasterized versions of their fonts, not suggesting an alternative to the @font-face support.
Their claim is pathetic, based on hypothetical misrepresentation. I hope they save face and drop it, and maybe rethink how how many lawyers a community college needs.
I wouldn't put all those messages up there with my own copyright notice. Besides that, I only see profile pics next to a few cyclists, so that could use a fix. Seems like this could be useful to someone in that community--maybe try pulling out trends, the way Twitter does across the whole service.
Digg can avoid pissing people off with this by adding their own framebuster. If the frameset's HTTP referrer is Digg, then the DiggBar is a potentially useful toolbar. If the referrer is something else, it should redirect to the original page.
If you figure out the answer to this, politicians, PR people, and journalists will be knocking down your door. Once misinformation is publicized, it is very hard to correct. This can only be assuaged by making the public, through education or experience, less naïve and more likely to seek out the truth.
