Object Graphics Implementation

So, now that we've got at least a good rough specification to go by, I'm 
ready to start coding it to see what we're missing.  I think it's time to 
at least start thinking about the implementation details (I realize that 
the spec will be changing, but the general ideas are there and good).

How do we want to handle the specifics.  I'm starting from what I see in 
John's handle-graphics.tar.gz.

Object numbers:

He has three object stores: root, figure, and all others.  Root's object = 
0, figure's objects are positive integers, and the others are negative 
integers.  While I initially thought that I preferred Matlab's style 
(figure number.object number), I now realize that it doesn't really 
matter.  One thing that I don't like quite as much with the negative 
numbers being used I originally thought that I was seeing an error code 
returned.  It's a minor complaint, but it may confuse some people 
at least initially.

Structure of the stores:

Since (at least as it's written now), there are two "figure" type objects 
(figure and movie) and many other type objects (patch, line, surface, etc) 
they will all have the same structure (i.e. only axes have the TickLength 
property, but with everything in one structure lines, patches, and 
surfaces will have the property, but it will be empty for them).  This 
works rather well for finding things within the handles, though.  The 
other option I can think of is a cell array of structures, but while the 
data itself is cleaner, the data access becomes more complex with this 
methodology.

I think that I prefer the single structure with empty properties when they 
aren't needed, but I'd like input if you have an opinion.

Are there any additional comments on these or other implementation details 
that need to be considered?

I hope to use my commuting time this week to add to what John started with 
handle-graphics.tar.gz.

Bill

-- 
"If you're so special, why aren't you dead?"  -- The Breeders