Once I get going on something like this, I just don't want to stop. It's going to bug me all day at work today. This function brings back visions of architectural drafting in high school.
An interesting thing I found: When you draw the arc, it conforms to the angle from which you have created. However, if you append to the arc, it does not append to the ever-floating end of the arc, but to the "toPoint:" argument (!). That means the computer will go back and connect itself, thus drawing an ugly line where none originally existed. This intuitively does not make sense, but from a computer programmer's point of view it is necessary.
One of the weaknesses of this function is it's reliance on static points. If you want to make a continuous path, you _have_ to know that your end point is at precisely the point at which the arc becomes tangent to the second line. The second point of tangential contact is equidistant from the apex as the first point of tangential contact. Using manual drafting means, you could discover these points by drawing an arc using the apex as the center point for your compass. You could then find the arc's center by drawing two separate arcs of the desired radial length from each of the two end points, the center being at the intersection point. Then finally, you would draw the arc while carefully erasing all of the other lines.
Unfortunately, we do not have the convenience of a compass to measure where the second point should be. Up to this point it has just been a static point. This is insufficient. We need to find a way to calculate this point and have it change automatically to accommodate the changes in the arc's radius. We need to do the same for the starting point, as I have noticed the arc does not necessarily start at our starting point, but wherever it is mathematically to do so. The starting point, fromPoint and toPoint are used as guides for arc creation but starting or ending points for subsequent path creation. I'll have to think about this one and post more later.