[Grace-core] Obejctdraw

[James Noble]

> 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....?]

well yes we could, but I don't want to end up having to build a whole "platform" (as the haskell people call it)

> 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.

>  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 

> 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.

??

> 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). 

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



> 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...

James