<div dir="ltr">Thanks for the feedback! I'll just note here that I wrote up the pdf on Friday afternoon, quite a rushed job so it might not be completely easy to follow.<div>We were more interested in just getting it out there so we could get some feedback. If you want to see how to library actually feels when using it in programs I suggest</div>
<div style>looking at some of the test_Graphics_* files in <a href="https://github.com/AlexSandilands/grace-phix/tree/master/testing">https://github.com/AlexSandilands/grace-phix/tree/master/testing</a></div>

<div><br></div><div style>Thanks for all the great questions and suggestions, I'd like to respond to all of them but this email would be far too long :(</div><div style>I'll try to just go over a few of the major ones.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

There were so few objects in the interfaces</blockquote><div><br></div><div>I think I made a mistake in the design of the api. I didn't make clear that sections 2 to 7 are grace modules. So section 2 covers the graphics.grace module, section 3 is window.grace etc.</div>


<div>Section 7 covers three utility modules.</div><div><br></div><div>The only modules that don't use objects are graphics.grace and the utilities, and this was a design choice. All the other modules use objects.</div>
<div>
<br>
</div><div>As I explained in the graphics.grace section, that module is a listing of constructors for the objects that are in the library. It didn't make sense to me for</div><div>graphics.grace to use an object for this. Let me explain with some example programs</div>


<div><br></div><div>// 1</div><div><br></div><div>import "graphics" as g</div><div><br></div><div>def w = g.createWindow</div><div><br></div><div>w.display</div><div><br></div><div>// 2</div><div><br></div><div>


import "graphics" as g</div><div><br></div><div>def gObj = g.aGraphicsObj</div><div><br></div><div>def w = gObj.createWindow</div><div><br></div><div>w.display</div><div><br></div><div>As you can see it just makes another line of code that isn't necessary in my opinion. Since there are only constructor methods in graphics.grace, there doesn't need to be an object</div>


<div>to pass around, as any file that imports graphics.grace has access to exactly the same information, and that information isn't changeable.</div><div style>You might argue that it isn't necessary for there to be a module that is dedicated to listing the object constructors since you could just import window.grace, canvas.grace etc, </div>
<div style>but this way when you want to write a program using Grace-Phix the only import you need is graphics.grace. This takes away a big nasty load of imports that you have to deal with, something that</div><div style>
Java does badly. This way seems nicer to me.</div><div><br></div><div>Exactly the same reasoning for GMath.grace, it wouldn't make sense to me to create a math object, then use that object to perform operations. It's not like we require GMath itself to store any user data.</div>


<div>It just has methods that perform calculations. One of the notes suggested that all the methods should just be on Numbers, which is probably a good idea. However, I kind of like the idea of Numbers</div><div>having all the basic operations like +, - etc, then when you want to start doing complex math you import a math module. Probably something worth talking about.</div>

<div><br></div><div>Color.grace is slightly different. There is a color object as this is something that needs to be passed around, and store user data. However there are also a bunch of constructor methods in the module outside</div>


<div>of the color object which just make it easier to use.</div><div><br></div><div>For example you could do</div><div><br></div><div>import "Color" as col</div><div><br></div><div>def c1 = col.aColor(1, 0, 0)</div>


<div><br></div><div>// Or, to make it easier and more readable</div><div><br></div><div>def c2 = col.red</div><div><br></div><div>red() is a method inside the Color module, but it isn't inside the Color object, why would/should it be? Create an object so you can create another object?</div>

<div>In Grace you can't overload/override constructors. class aColor -> Color { ... } is really just sugar for a method that constructs and returns an object, right?</div><div>Since we can't overload that, what I like to do in Grace is have the class aColor ... etc and also have a list of methods in the module that construct</div>

<div>the object in different ways. A nice way to replace overloading in my opinion. Is this not something that was intended in the language?</div><div><br></div><div style>Apart from those, everything else is an object. Unless I am misunderstanding what you mean.</div>
<div style><br></div><div style>--------------------------------------</div><div style><br></div><div style>It seems there was some confusion as to how a canvas works, so I'll clear that up now.</div><div style>Canvas is a component that you can call paint() on. One of the notes said that I haven't explained what the display buffer is so you don't yet know what I mean by that.</div>
<div style>Well, it all depends on which backend you're using, which is why I didn't elaborate. With the GTK backend the canvas is a gtk.drawing_area, with the JS backend it is a canvas.</div><div style><br></div>
<div style>The Grace-Phix canvas object has a list of Drawable objects. When you call paint on the canvas, every Drawable on this list has their draw methods called  (unless one of them has been set as hidden etc).</div><div style>
There are two ways that you can add Drawables to the canvas. Either use graphics.grace to construct a Drawable object then add it to the canvas, like this:</div><div style><br></div><div style>import "graphics" as g</div>
<div style>import "Color" as col</div><div style><br></div><div style>...</div><div style><br></div><div style>def can = g.createCanvas</div><div style>def cir = g.createCircleAround(20, 20) radius(5) colored(col.blue)</div>
<div style>canvas.add(cir)</div><div style><br></div><div style>...</div><div style><br></div><div style>or you can call the drawing methods that the canvas object itself has, like this:</div><div style><br></div><div style>
import "graphics" as g</div><div style>import "Color" as col</div><div style><br></div><div style>...</div><div style><br></div><div style>def can = g.createCanvas</div><div style>can.color := col.blue</div>
<div style>canvas.drawCircleAround(20, 20) radius(5)</div><div style><br></div><div style>...</div><div style><br></div><div style><br></div><div style>Both of those code excerpts do exactly the same thing.</div><div style>
<br></div><div style>I like having the two options available. This way you can create your own Drawable objects, such as a Teeshirt from Kim's example, and add them to the canvas,</div><div style>or if you are needing to do a loop or something and draw hundreds of basic shapes, all of the same color, you can just set the canvas to have that color and </div>
<div style>start calling the canvas draw methods.</div><div style><br></div><div style>-----------------------</div><div style><br></div><div style>There were some questions about the Drawable objects themselves. A Drawable is essentially just something that has Cartesian coordinates and a draw method, which takes</div>
<div style>a graphical drawing object. ie if using the GTK backend the draw method would take a Cairo object, if using the JavaScript backend the draw method would take a canvas context object.</div><div style>This shows off some of the flexibility of the library. If you wanted to use a different backend, all you need to do to get the Drawable module working is change is the body of the draw methods. Everything else</div>
<div style>will work just fine.</div><div style><br></div><div style>-------------------------</div><div style><br></div><div style>There were some good suggestions for changing method names and things like, I'll go through and do that, thanks.</div>
<div style><br></div><div style>The idea is that when both the GTK and JavaScript backends are finished, we will rewrite ObjectDraw using Grace-Phix. Then any applications written with the new ObjectDraw will run on gtk and the WebIDE</div>
<div style>in a very elegant and flexible way.</div><div style><br></div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 25, 2014 at 9:29 PM, Andrew P Black <span dir="ltr"><<a href="mailto:black@cs.pdx.edu" target="_blank">black@cs.pdx.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Alex,<br>
<br>
Thanks so much for sharing this.  I have put a few comments throughout the document, as little yellow “post-it notes”.  Most are suggestions for renaming, simplification, or completeness.<br>
<br>
Overall, it’s great that you are discussing this interface.  I was a bit surprised, though, that there were so few objects in the interfaces; it read more like a functional language library, where everything had to be a top-level function because they don’t have objects and methods.  I think that Phix can be simplified a lot if you take advantage of objects.<br>

<span class="HOEnZb"><font color="#888888"><br>
        Andrew<br>
</font></span></blockquote></div><br></div>