[QUANTITY] and [OBSERVATION] data models: mutability (off topic?)

[Martin Hill]

On Wednesday 05 May 2004 1:19 pm, David Berry wrote:
> Martin,
>
> > > That's certainly a possibility. It would be particularly relevant I
> > > guess for multi-threaded access to the Quantity. But on the other side
> > > of the balance is the expense of object creation in most OO languages.
> >
> > It applies not just to multi-threaded access, but any occasion where
> > more than one reference is held (I'm in a bit of a rush just now but can
> > do examples for next week if need be).  The object creation overhead is
> > a red herring at this stage!  It only really matters in tight, large
> > loops where Quantity is likely to be inappropriately heavyweight anyway.
>
> In single-threaded situations it should be possible to keep track of what
> is happening to the Quantity. For instance, if you have two active
> references to a single Quantity, and you pass one into a method which
> changes the current Frame properties, then this method should advertise
> this in its public contract. The calling code should then take account of
> the possibility that the Frame properties may have changed when using the
> either reference.

Consider two UI views (one showing an RA & DEC 'grid', the other an HTM 
overlay) on the same object.  They both run on the same thread but neither 
know (or should know) about the other. We don't want each continuously 
changing the objects frame - they should either be asking for data with in a 
certain frame (ie, applying the frame along with the request) or using a 
different instance. Any other loosely-coupled code structures will have the 
same problem.

It may be that we don't need to make the whole Quantity immutable, but we do 
need to make sure that any changes to an instance have enough context 
information with them

>
> The rule should be that code never makes any permanent changes to an
> object supplied by the caller unless it clearly advertises the fact in
> its public contract. Then it is the responsibility of the caller to take
> account of this contract.

Unfortunately few programming languages enforce this level of contract at a 
method level.  Yet! And in this environment, where code is likely to use 3rd 
party libraries, we can't rely on documentation.  So in fact we are left the 
other way around - calling code cannot assume that objects will not be 
changed.  Where this might cause problems, we make objects that *cannot* be 
changed.

>
> Of course, all this becomes much more complicated in multi-threaded
> situations. For which reason copying rather than modifying may be the way
> forward.

Yes multithreaded adds another layer of issues to do with changes, but these 
are resolvable if changes are required.

Cheers,

Martin

(Not so much of a rush after all - train leaves 4 hrs after I thought it 
was... doh)

-- 
Martin Hill
Astrogrid/AVO, ROE
Tel: 07901 55 24 66