[Grace-core] Obejctdraw

[James Noble]

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

Oh OK...
> 
> But  it is not OO, is it?

Processing - no it isn't. 

>  The objectdraw library is also immediate (create an object and it shows, move it and you see the difference),

ObjectDraw is retained: yours creating objects with identity, you can modify them later, and crucially you don't have to redraw at every frame. 

> - it is almost enough to pull me over to that side!]

Well that's good then... That you're teetering I mean...

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

Ok yep makes sense.. 
> 
> 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.

I guess so!   But I'd hope you wouldn't do that for small value objects like fractions or points!

>> 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 can't

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