> I would like to know if PHP's object implementation, which was introduced after their associative arrays, suffers from the same hash collision issues.
I was curious myself, so I went digging. Most of this stuff appears in `Zend/zend_object_handlers.c`. For objects with std_object_handlers set up on them (which I assume is most of them), zend_std_read_property can do quite a bit of work: it tries a search of the property info hash zobj->ce, then the zobj->properties hash, and then calling `__get()` with protection against __get loops, then giving up and returning null. zend_hash_quick_find(), as used for these lookups, takes a HashTable* as its first argument, which is also the type of a hash table in zvalue_value.
Thus, object properties are associative arrays, though I don't think there's an equivalent severity of attack compared to causing collisions with crafted GET/POST data, as the latter is automatically parsed. You'd have to be able to upload code to make evil objects.
Not sure if serious, but consider English "to", "too", and "two".
Disclaimer/explanation: I actually studied Japanese, but I'm assuming the same principle applies. If so, the symbols would be different because of the differing meanings, and the pronunciation is coincidental.
The technical quality of the photos is quite poor. They're way too bright if we're looking for subpixels, since all we see are full pixels, smeared together into blooming white. Also, looking at the HTC Rezound's standard color test, the Verizon logo on the phone is blurred just like the display itself.
It would help if the photos were re-done to actually show subpixels, sharply. (Edit: unless I missed the point, in which case the Settings menu shot should suffice: "It's PenTile but it looks pretty nice in actual usage!")
I was going to attempt this, but the solution was posted inline in the blog entry, and I read it by accident. My window was just big enough that it was the last line displayed. =(
Microsoft abandoned the "My" prefix in Vista for Documents, Pictures, etc. in the UI.
And then they brought it back in 7. I guess people complained.
I agree that omitting the "My" or "Your" where possible is the right way to go. If the overall context of the web page or application doesn't make it clear whose items are in question, adding "My" isn't always going to help much, or at all.
Consider Facebook, for example. Look at a friend's page. It probably has a "Photos" link. Would "My Photos" be clearer? Would "My Photos" refer to photos belonging to the logged-in user or photos belonging to the person depicted above the link?
It's the context in which the "Photos" link appears that makes its purpose and meaning clear, and that is usually the case.
Actually, it took me a while to figure out why "Photos" didn't take my to My photos, but to a photo stream of all of my friends. (Also, Win7 did not add the "My" prefix back to computer, documents, pictures, or anything.)
In fairness, there are aliases of some kind set up such that "John\Documents" and "John\My Documents" are synonyms. But the GUI very much puts "My" front and center for me.
Speaking of context, though, I've also heard "don't use My" as a recommendation for mobile UIs, because they don't have that much space to spend on the word to begin with...
When an article about the problem is published on a gaming site, after it makes the point, it's got a couple of gratuitous chick images stuffed in it, with captions like "Bet you're paying attention to what I have to say now!"... Hmm.
I have always hated "You are male, YOU WILL LIKE THIS CHICK" flavored messages, and this still bothers me. Especially in an article like this.
There's another mistake in that command (also present in the article): with that "t" in there, `yt$` will yank up to, but not including, a '$' character on the current line. Unless there is no '$', which is an error and no yanking. Yank from cursor, not including newline, is `y$` without a "t".
+= does union-by-key: any keys present in the right array, and not in the left, are appended to the left.
`array_merge` will append all numeric keys from the right array to the left, under new key values, as if you used [] one-by-one; for string keys, all keys from the right are copied into the left, possibly overwriting what was there.
In real code, I either have all-numeric or all-string keys, and `array_merge` does what I want in bulk operations: it's essentially equal to Python list.extend and dict.update, respectively. `+` on arrays is basically useless for me.
> Is the theory that true "hackers" care more about the programming language syntax and semantics than whether it has the right libraries for the subject domain of the startup? Is the theory that true "hackers" care more about whether the startup uses a new and un-tested programming language than traction, likelihood of success, money, or the actual problems being solved?
As a basically useless anecdote... for random mucking around, I use whatever language sounds interesting. This has been Perl, Python, Forth, CL, Clojure, Ruby, and many others by now. (I used to consider myself a hacker, until I realized I wasn't working on any hard problems.)
But for real business, I'd choose something I know I can deliver with, which is pretty much Perl, C, or PHP for me. I've tried to extend this set by playing in Java and C# a few times, but the interest just isn't there. (Edit: I don't seem to have any problem delivering on boring problems in php, though.)
Contrary to what he wrote here, Steve actually has ragged on Amazon in the past, in particular in "Have You Ever Legalized Marijuana?" -- the imagery of Amazon doing things by burning through people like little tea-lights really stuck in my mind.
I was curious myself, so I went digging. Most of this stuff appears in `Zend/zend_object_handlers.c`. For objects with std_object_handlers set up on them (which I assume is most of them), zend_std_read_property can do quite a bit of work: it tries a search of the property info hash zobj->ce, then the zobj->properties hash, and then calling `__get()` with protection against __get loops, then giving up and returning null. zend_hash_quick_find(), as used for these lookups, takes a HashTable* as its first argument, which is also the type of a hash table in zvalue_value.
Thus, object properties are associative arrays, though I don't think there's an equivalent severity of attack compared to causing collisions with crafted GET/POST data, as the latter is automatically parsed. You'd have to be able to upload code to make evil objects.
Going through this exercise was fun, though:
The "property starts '\0'" case is specially checked by the standard property handler, with no explanation...