<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> Heh, I used to call it box in my DOS programs. But, the functions<br>
> it forwards to are called Rectangle() and XDrawRectangle(), so<br>
> I want to be consistent with them so it's not a surprise to<br>
> someone already familiar with with the other APIs.<br>
<br>
</div>I don't agree. line(), box(), circle(), etc are so easy to remember and common that I don't see the need to keep the names of the functions under them.<br>
<div class="im"><br>
<br>
> The reason I went with drawShape instead of just Shape is that<br>
> functions are verbs, so generally, I like their names to be<br>
> verbs too. There's exceptions, of course, but I don't these<br>
> fit.<br>
<br>
</div>I don't agree. It's _very_ easy to understand that p.line() is to add a line, there is no chance of confusion here, the verb of p.drawLine() is implied.<br>
<div class="im"><br></div></blockquote><div> </div><div>I would argue that p.line is inconsistent with an immediate-mode drawing API design (it just strikes me as weird all around actually.)  If this were retained mode, something like p.Add(Line(...)) would make sense.  But if the action is to draw a line, and the target of that action is object p, then p.drawLine is the most sensible.  The objective here is not to relieve the user of typing, but to ensure the code is unambiguously clear.  Imagine p.box. What does that mean?  Draw a box?  Or are we boxing p into some portable format?  I agree with Adam's original thought that methods should be verbs.  At least to my mind is reads easier.  YMMV.</div>
<div><br></div><div>- Cliff</div></div>