,
7 tweets,
2 min read
Read on Twitter
Since WebKit is open source, it’s possible to do some code archaeology about NSError, at least for as long as IFError, the progenitor of NSError, was in WebKit. IFError’s first appearance is in the linked revision. 1/ trac.webkit.org/changeset/696/…
IF was a two-letter prefix for “Internet Foundation”, and for a time, it was the prefix we used for low-level networking classes in Safari/WebKit. 2/
Sometime later, the IF-prefixed classes related to URL loading moved to a short-lived WebFoundation framework, and the code took on a three-letter “Web” prefix. Eventually, many of these classes were integrated into Foundation itself, and WebFoundation went away. 3/
Error domains showed up in the linked revision. The comment and bug number are still visible, even though you can no longer see the IFError revisions, since the code had moved out of WebKit and into WebFoundation, which was never open sourced. 4/ trac.webkit.org/changeset/1129…
In the same way that classes like IFURLRequest became WebURLRequest became NSURLRequest, what started as IFError became NSError, and at with that last tranisiton, the class passed into the steady and expert maintenance of the Foundation team. 5/
The word “archaeology” I used at the start of this thread is apt, since this is much like digging up old fossils and trying to understand how things came to be as they are, based on looking at things as they were. 6/
It might be impossible to understand the full history of NSError without my (admittedly imperfect) memory of what happened. Of course, this story matters very little in the big picture. Yet, it's a cautionary tale. Most things are more complicated than they seem. 7/x
