Re: Clean Object Class Design -- What is it?

> The person who posted the examples left out the crucial set-level
> assignment operation:
>
> insert(x,S):
> x = x union S
> remove(x,S):
> x = x difference S

um, I still don't quite see it, unless these are funtion definitions that should read

  insert(x,S) isDefinedAs S = S union {x}   remove(x,S) isDefinedAs S = S difference {x}

> In any case, regardless whether they are mathematical set operators,
> they are set-level operations in that they operate on sets, which
> allow the DBMS to determine the best algorithm to use for navigating
> and changing individual values.

To be honest, I cannot see that. For example, the value-returning set expression

  S = S difference {x}

could be enormously inefficient. Suppose the set contains 20,000 elements, none of which is x? The RHS expression constructs a massive copy of it. Then the table of items referred to by S is slowly overwritten, item by item, by the new dentical copy. But I thought good RDBMS does do excellent optimisations, based on the state-oriented nature of updates.
  "remove(x,S)"
is a side-effect specifying operation on S. Optimal approach is to take minimal path to inducing the desired side effect, not breaking down into separate set operations.

> Contrast them with operations that
> operate on single records requiring user-specified navigation.

Yes, that's ugly.

> My original post did not claim they were mathematical set operators.

my misunderstanding

> > [ some definitions ]
 

> This is a very important point, because (in my experience) many of
> the OO proponents do not understand the difference between values
> and variables or between operators and mutators.

I'd say these are ignorant people. They are to be found (as bandwagon-jumpers) in association with almost any software area. More useful to stick with the professional practitioners, who may also be proponents. Ignore the joy riders!

-- 
http://www.mk.dmu.ac.uk/~gperkins/