[Grace-core] Obejctdraw

[Kim Bruce]

Andrew makes an excellent point on the philosophies for libraries -- and that we need to talk about them to see what we want.  [Although i can also see a case being made for multiple libraries e.g., several graphics libraries -- though there are dangers as well.  Perhaps we could even have beginner and advanced libraries....?]

When we were making up the objectdraw library, we consciously designed it to be minimal.  In fact at one point we almost came to blows about including a line that was specified by a starting point and angle (as being too advanced!).  For novices, it is very important that things be as simple as possible (though no simpler).  The code needs to be as accessible to art studio majors as to physics majors.  In particular, students should be able to easily peruse the documentation, understand what the various methods are, and find what they are looking for.

Moreover, because a key idea is to use primitives to build objects that can be treated themselves as primitives, it is important that there be stuff for them to do.

I suggest a good test for designing libraries for novices is to think about the kind of programs that students will be writing and making sure they have what they need.  I know a lot of the graphics libraries that people are using to teach novices.  They tend to be relatively simple, though some people use the regular Java AWT/Swing libraries (ugh!).

As to Andrew's other "point" (or should I say GPoint), while I am sympathetic to having Point be immutable, if you are allowing the geometic objects to be mutable, then likely you want them to have Points as instance variables.  Thus when you move them, you will need to move those Points rather than create new ones. Of course you can always create new Points on the fly, but that's pretty inefficient.  I believe that is why we made Locations mutable in objectdraw.

I suspect we may want to have both mutable and immutable points.

Kim



On Dec 20, 2013, at 12:34 PM, PSU via GMail <andrew.p.black at gmail.com> wrote:

> On Dec 21, 2013, at 9:04, Kim Bruce <kim at cs.pomona.edu> wrote:
> 
>> The ACM Java graphics library uses GPoint.
> 
> I looked at GPoint.   It's mutable, which I'm sure is just WRONG.   It has one non-trivial method, translate, which is like + except that the argument is an xy pair instead of a GPoint.  (This is Jave, so  they can't call it +.).  Nothing here to imitate that I can see.
> 
> I think that there are two philosophies for libraries.  One is to make them minimal, so that students can see the WHOLE of every interface, and can be given assignments to enhance them (once we figure out how to open classes).  The other is to make them rich, so that students can learn to read documentation, and write interesting apps that USE the libraries.    An example in Graphics might be asking a point which side of a line it lies on.   This is a primitive in many algorithms, like convex hull; should it be "given" to students, or should they write it?  An example on collections is do()separatedBy(), which is frequently useful for manipulating a collection, e.g., printing a list.
> 
> We should talk about this philosophy before talking about a particular case.  
> 
>     Andrew