116 karma · joined April 3, 2011
So we have that Python's dot always binds, Ruby's dot always calls, and Lua's dot is always a table lookup, with Lua's colon being a separate syntax for (always) the compound operation with injected self-argument.
And then JavaScript is the schizophrenic one: « obj.foo(bar) » is not the same as « var y = obj.foo; y(bar) ». Property lookup and function call insert a hidden step between them when and only when directly composed, and a function call without an immediately adjacent property lookup in a way injects the opposite step of making « this » in the callee be the global object (I think). “Politicians lie in cast iron sinks.”
That's mainly why I wrote “at most” instead of trying to compute the exact available number, yes.
You don't even theoretically need application-layer gateways to multiply the effective number of ports by a large factor for common loads, of course, as I mentioned; I just erroneously thought such technique was not in common use, per my reply to eggnet.
foo = { x = 3 }
function foo:bar(baz)
return function(thud)
return thud + baz + self.x
end
end
womble = foo:bar(4)
womble(7) --> 14
Python I believe also closes over self as a variable, and Ruby has similar behavior for local procs, even though « self » is a special form in Ruby.This is in distinct contrast to JavaScript, where the value of the special form « this » goes nuts inside closures because it's attached to the function:
foo = { x: 3 };
foo.bar = function(baz) {
return function(thud) {
return thud + baz + this.x;
};
};
womble = foo.bar(4);
womble(7) # --> NaN
So in what way are you placing Lua and JavaScript together, and Python and Ruby together?[slightly rearranged for clarity]
(I'm not Pernese myself, though I am a drake. But it seems fitting.)
Edit: U+2588 seems like an obvious candidate as well.
If you like you can add the “compatible” though, which would conveniently add to the length.
It seems like it would have potential for confusion, but it strongly depends on the application and its context. It's possible for the author to partially work around this by providing what amounts to an extra URI indicator (similar to “permalink” markers in blogs and other time-dependent views of content stores), but this is awkward. (Is there an add-on library for that, for that matter?)
As a counterpoint, I regularly use different Sneakemail addresses on different sites to be able to categorize my mail by origin and provide for limited sending capabilities. These are random-like (in order, among other things, to not be trivial to link to each other) and perfectly machine-readable, but they're difficult to use as usernames. So the trend of “email address as the only acceptable identifier for login” makes things more awkward for me. (This obviously doesn't apply if you allow associating a short name as well.)
A trivial hello-world in Java takes ~130 ms on my Debian sid box with « OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-4) / OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode) ». This is with all default runtime options.
The program « (ns hello (:gen-class)) (defn -main [] (println "Hello, world!")) » compiled with Clojure 1.2.0 (again from Debian sid) takes ~1700 ms. Using -Xbootclasspath takes it down to ~800 ms. -client doesn't do anything obvious. Unpacking the Clojure JAR increases the time.
So presumably there's something about pulling in the Clojure runtime pieces that is very slow, but I have no idea what it is.
I'm not sure I understand what you're saying here. TTBOMK, Google, Yahoo!, and Windows Live ID are all also OpenID providers. E.g., the Isotropic online Dominion server allows users to “log in with a Google or Yahoo! account” with an OpenID backend.
So if your thesis is that people reject OpenID because they can't extend their identities from those existing accounts, I don't see how that's the case, unless the OPs have restrictions I'm unaware of. (People might not know they can identify themselves with those accounts, which I think is a real problem, but a separate one.)
Implementationally, hooking up an extra MIME layer is a lot more cumbersome than it should be. This is theoretically a transient characteristic, but I have the creeping feeling that that will destroy any attempts to use MIME for this purpose regardless.