Re: syntactic sugar vs. design

[Andrae Muys <amuys shortech com au>]

Byron Ellacott wrote:
> 
> On Wed, 28 Feb 2001, Andrae Muys wrote:
> 
> > I must admit that coming from an engineering background I can't help but
> > think of vectors and ordered-pairs as fundamental types :).  Hence I
> > don't have a problem with them.  Granted they can be abused by lazy
> > developers, but then again Strings are already being abused worse than
> 
> The difference is vectors and ordered-pairs are not atomic - so when you
> want a vector of complex types, you'll give yourself nightmares, or have
> to have two cases for dealing with vectors.  Strings may be abused, but
> that's an application developer's problem, not a data model problem.

A vector/pair should represent a single quantity as such any change can
and should be treated atomically.  There shouldn't be any attempt to
permit atomic updates to elements of the vector/pair.  Consider a colour
vector, a change to any component is a colour change.  Any attempt to
permit independent changes is fundamentally broken.

Consider two applications changing a single colour vector (I'll use RGB)

Init = [00,00,00]
App1 changes colour to blue, App2 changes colour to red.

valid results are :
[00,00,ff] - App 2 get's colour changed signal.
[ff,00,00] - App 1 get's colour changed signal.

However with element based atomic operations you can also end up with:
[ff,00,ff] - App 1 and App 2 both get colour changed signal and update
to corrupted value.

Which is obviously incorrect.  Worse, it may (depending on
implementation) become possible for App1 and App2 to become out of sync
with gconf if the changed signal is lost.

If however the values are truely independent and such changes are
permitted they should be independent key/value pairs in a directory, not
elements of a vector.

Naturally the same argument applies for pairs, in fact if we ever want
to support any form of engineering application in GConf, support for
complex numbers (read pairs) will be important.

> >     GNode *tree = gconf_get_tree("/apps/myapp/colour");
> >     Colour colour;
> >     colour.r = gconf_tree_get_int(tree->children);
> >     colour.g = gconf_tree_get_int(tree->children->next);
> >     colour.b = gconf_tree_get_int(tree->children->next->next);
> 
> The problem with this is it now relies on the ordering of r, g and b in
> the data, requiring either more work from the application, to ensure the
> node you expect is the node you get, or more work in the engine, to ensure
> nodes are at the very least returned in the right order, and only the
> nodes you want are returned, and that all the nodes you want are
> returned.
> 
> I'm not sure what gains a tree interface would offer over accesing "r",
> "g" and "b" directly?
> 

Heh, thanks.  I knew I would have stuffed up the proposal somewhere :).

Oh well, time to rethink that bit at least.

Andrae