[Grace-core] Obejctdraw

[Kim Bruce]

> 
> 
>> 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!).
> 
> and that was left out?  pity -  it means you can't do clock faces without having to do the trig yourself.

It is in there as a class AngLine.  I was in favor of keeping it.  We needed a separate class because of Java rules about names for constructors.
> 
>> 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.
> 
> right. which is why I first stared off proposing processing as the graphics API.
> Processing's API doesn't use points, doesn't use separate graphics context objects
> (but has a big implicit graphics state instead, so is non-threadsafe)
> and it's an immediate (imperative drawing) model, rather than retained objects.
> 
> it is used very successfully by all sorts of graphics and music people 

But  it is not OO, is it?  The objectdraw library is also immediate (create an object and it shows, move it and you see the difference), but is nicely OO.  I do appreciate both the argument to use Point instead of x, y, and yet the pain of creating all these locations, having used them to write a bunch of programs.  I suspect that we may yet again be forced to duplicate methods (but not overload!) so that each can be done both with points and with separate x,y.  We did that in objectdraw and it made it easy for us to choose the appropriate version depending on what was the easiest.  [And yes, I see that as the major argument for using "@" as Andrew suggested -- it is almost enough to pull me over to that side!]
> 
>> 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.
> 
> ??

Sorry, I'm getting punchy with grading.  We want students to define new classes (TShirts is one of our favorites) and then use them as if they were built in primitives.  I.e., TShirts can be used as simply as framed rectangles.
> 
>> 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.
> 
> with a good generational collection (Javascript has one, we don't on C), efficiency is no more of a problem than e.g. arbitrary
> precision rationals or fractions. Point algebra makes and discards a lot of small objects quickly, they don't last long.
> I mean they're basically just dotted pairs (conses) in LISP terms. 
> Racket has moved to primarily immutable conses, and we'd like our literal strings and lists/ tuples to be immutable (I presume). 

Yeah, that's reasonable.  Now, however I beat up on students for gratuitously creating new objects when they could recycle old ones.  Force of habit, I suppose.
> 
> the real question with mutablity comes with sharing (aliasing)  --- ((what else did you expect me to say?))
> this again is about the underlying abstractions of the library.  Hotdraw (I seem to remember) used 
> Locations that could be intentionally shared and propagated changes to manage that sharing.  
> You could move an object by moving a locator to which it was attached, and that would 
> and changes would flow around the system (e.g. talking to a proper constraint solver)
> But this seems different to an essentially mathematic abstraction of a point on a cartesian plane
> (or, again, a complex number)
> 
> http://c2.com/doc/crc/draw.html

Yes, sharing of mutable state is a big problem.  We could also let the students play with immutable points, but store them internally as mutable, I suppose (making sure we convert back to immutable before they escape).
> 
> 
> 
>> I suspect we may want to have both mutable and immutable points.
> 
> I fear that way lies madness....
> although I've almost convined myself that primitive, low, level immutable points,
> and higher level, mutable, sharable, constrainable locations may be what is needed...

That's probably what I'm suggesting above.
> 
> James