On 4/11/2017 10:41 PM, WarGrey Gyoudmon Ju wrote:
This is a little awkward, there are lots of simple classes defined in
racket/draw, font%, color%, pen%, brush% and so on. They just hold a
group of plain data, hence opportunities to be inspected easily.
However by default all classes are opaque, the easiest (and perhaps
unique) way to handle this is to inherit them and implement the
`printable<%>` or `writable<%>`.
Despite the wordy code and wasting little runtime space, the major
problem is all those classes hide their (set-immutable) methods, even
worse, the immutability is checked through the private field. As a
consequence, subclasses of Pen% and Brush% copy color instances every
time to make them immutable (and opaque) again...
So is it okay to open that interface?
A lot of graphic APIs - Windows, X, Display Postscript, etc. -
discourage modifying a resource while the resource is selected in a
drawing context. Of course, you aren't actively prevented from doing
it ... but bad things - including serious crashes - may happen if you
touch something at exactly the wrong time. Colors and pens are
degenerate examples - the bitmaps associated with brushes and
raster(ized) fonts are more representative of the problem.
If you make the (Racket) objects mutable, I would worry that people
might be tempted to mess with them at inappropriate times. Raw graphic
APIs don't protect you from being stupid ... Racket's API at least tries
to. I suppose an alternative would be to lock the objects while they
are selected, but I don't know how easy that would be to implement.
Just my $0.02
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
