Re: [firstPath appendBezierPath: [secondPath bezierPathByReversingPath]];
Re: [firstPath appendBezierPath: [secondPath bezierPathByReversingPath]];
- Subject: Re: [firstPath appendBezierPath: [secondPath bezierPathByReversingPath]];
- From: Hamish Allan <email@hidden>
- Date: Mon, 24 May 2004 17:11:09 +0100
Bob,
As a practical matter, a human being drawing a circle (or a computer
stroking an
[ approximately :-) ] circular path) most certainly does: you have to
put the pen down
_somewhere_ when you begin.
You're making my point for me: if I ask you to draw a circle, you have
to put the pen down somewhere, but you don't ask me where you should
put the pen down first, you just go on and draw the circle putting the
pen down wherever you feel like it, because it doesn't matter.
I think I begin to see the problem: you are attached to certain
(pedantic in my view) ideals
of notational purity. When I was a physicist, I was an experimentalist
not a theorist and the attitude caries over into software engineering:
I am much more interested in making interesting stuff that works than
in discussions of notation or representation. I am not bothered by the
moveTo among the lineTo's - I'm just happy that it draws the path I
asked for.
No, I want to make stuff that works too. I've said again and again what
my pragmatic reasons are for wanting this functionality, but you keep
ignoring them.
As for breaking things, consider carefully _all_ the implications of
what you ask for. The additional functionality won't immediately break
my program, but what if someone uses the new stuff to create some of
these beasties and then somehow gets one of them into a file that is
read into my program ? The non-standard creature will absolutely break
much of the 1700 lines of code in my NSBezier category and I will have
to go an rewrite them to test for the variant and then behave
differently. (I'm not really worried about this, I think the chances
that Apple would take you up on the suggestion are fairly small and
the chances that Adobe would modify pdf and PostScript in the same way
to be less than nil.)
"But what if someone" is a pretty weak argument. Using a text editor I
can change the contents of any file which can subsequently break your
program if it is not robust enough. So write less fragile code! Anyway
you still haven't explained HOW the "non-standard creature will
absolutely break much of the 1700 lines of code" in your NSBezierPath
category. How, how would it actually happen? What would actually break,
other than the sorts of breakage you would get by intentionally
changing the contents of the saved file produced by ANY program?
If you are going to wish for Apple to expend resources on
NSBezierPath, there are a host of more
useful things to ask for: easier editing of the path segments,
something that returns info about
the interior control points on either side of a control point on the
path (if you are moving the
point on the path in many cases you want to move all three so the join
angle or tangency is preserved), approximate offset of path, project a
point on a path, split path at point, etc, etc
I think you fail to understand quite how straightforward the change I
am proposing is. All Apple would need to do is to remove the logic
which says "you can't add a line without an existing point" and replace
it with logic that says "if you don't know where the start point of a
line is, take it from the end point of the last item in the path" (or
to put it more succinctly, "every path is circular"). It'd be great to
be able to edit paths in more sophisticated ways, but it would require
much larger changes to their internal data structures. Anyway, stop
trying to shift the goalposts: whether or not it would be a good use of
Apple's resources is an entirely different question from whether or not
it would cause problems.
Hamish
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.