David Weinberger wonders whether there need be a connection between on online reputation-identities (on one hand) and commerical identities (on the other), and in the comments Cory Doctorow muses that he’s not sure why we need anything other than client-side browser-based identity.
In hasty, spuerficial response, I would reckon that although David may want to keep “reputation” and “commerce” separate, that it’ll be a hard job to pry commercial entities’ tentacles away from conflating the two. I admire David for thinking it’s possible, though, and I support that vision—even if it subjects me to Eric’s aspersions of hippie-osity (hey, in this cultural climate, we could do with a lot more hippies).
As to Cory’s proposal, it sounds good to me, sounds like a set of protocols rather than an odious mediation. All we need is someone to write it and someone to implement it. . . .
Posted by AKMA at December 22, 2002 12:26 PM | TrackBackThese secret identities serve a variety of purposes, and they help us to understand how variables work. In this lesson, we'll be writing a little less code than we've done in previous articles, but we'll be taking a detailed look at how variables live and work.
Posted by: David at January 12, 2004 11:27 PMWhen the machine compiles your code, however, it does a little bit of translation. At run time, the computer sees nothing but 1s and 0s, which is all the computer ever sees: a continuous string of binary numbers that it can interpret in various ways.
Posted by: Cadwallader at January 12, 2004 11:27 PMWhen compared to the Stack, the Heap is a simple thing to understand. All the memory that's left over is "in the Heap" (excepting some special cases and some reserve). There is little structure, but in return for this freedom of movement you must create and destroy any boundaries you need. And it is always possible that the heap might simply not have enough space for you.
Posted by: Mary at January 12, 2004 11:27 PMLet's take a moment to reexamine that. What we've done here is create two variables. The first variable is in the Heap, and we're storing data in it. That's the obvious one. But the second variable is a pointer to the first one, and it exists on the Stack. This variable is the one that's really called favoriteNumber, and it's the one we're working with. It is important to remember that there are now two parts to our simple variable, one of which exists in each world. This kind of division is common is C, but omnipresent in Cocoa. When you start making objects, Cocoa makes them all in the Heap because the Stack isn't big enough to hold them. In Cocoa, you deal with objects through pointers everywhere and are actually forbidden from dealing with them directly.
Posted by: Sampson at January 13, 2004 09:06 AMA variable leads a simple life, full of activity but quite short (measured in nanoseconds, usually). It all begins when the program finds a variable declaration, and a variable is born into the world of the executing program. There are two possible places where the variable might live, but we will venture into that a little later.
Posted by: Melchior at January 13, 2004 09:06 AMOur next line looks familiar, except it starts with an asterisk. Again, we're using the star operator, and noting that this variable we're working with is a pointer. If we didn't, the computer would try to put the results of the right hand side of this statement (which evaluates to 6) into the pointer, overriding the value we need in the pointer, which is an address. This way, the computer knows to put the data not in the pointer, but into the place the pointer points to, which is in the Heap. So after this line, our int is living happily in the Heap, storing a value of 6, and our pointer tells us where that data is living.
Posted by: Joyce at January 13, 2004 09:07 AM