# Re: Proposal: 6NF

Date: 19 Oct 2006 15:33:15 -0700

Message-ID: <1161297195.838703.20460_at_b28g2000cwb.googlegroups.com>

On Oct 19, 7:06 am, "vc" <boston..._at_hotmail.com> wrote:

*> Jan Hidders wrote:
**> > vc wrote:
**> > > Jan Hidders wrote:
*

> > > [...]

*>
**> > > A much simpler example. Let {0, 1, 2, 3} be a set of four integers
**> > > with addition modulo 4. Then, none of its subsets, except {0} and
**> > > {0, 2}, retains the addition mod 4 operation which makes the idea of
**> > > 'subtype as subset' utterly silly, [....].
**> >
**> > You keep on making the same mistake. The expression a +[mod 4] b has a
**> > well defined result if a and b are from any subset of {0, 1, 2, 3}.
**>
**> Consider the subset {2, 3}. What is the result of (2+3) mod 4 ? If
**> you say it's '1', what is '1'? There is no such element in {2, 3}.
*

You're conflating math with type issues from OOPLs.

> > > Also, the OOP hypothetical programmer would expect that a subtype

*> > > would have, informally speaking, *more*
**> > > properties/operations/'methods', not less: the basic class properties
**> > > plus some new ones. So at the intuitive level with typical languages
**> > > like Java, 'subtype as subset' does not make much sense either, at
**> > > least with respect to even the simplest mathematical objects.
**>
**> > No, also from that perspective it works correctly. The superclass A
**> > would contain objects that understand the message plusMod4 with an
**> > argument that is in class A and return a result in class A. The objects
**> > in the subclass B would also understand this message with an argument
**> > in class A and return a result in class A.
**>
**> Objects in subclass B = {2, 3} won't understand 'plusMod4' because the
**> operation does not exist in B, it was lost as soon as you've subsetted
**> A = {0,1,2,3}. That is of course if you understand 'operation' in the
**> ordinary mathematical sense such that the set is closed under it. If
**> you have to go outside the set in question, it ain't no operation no
**> more in the accepted mathematical sense.
*

Certainly they will understand it. Behold:

class ModFour {

private final int val;

ModFour(int i) {

if (i < 0 || i > 3) throw new RuntimeException();
val = i;

}

public ModFour addModFour(ModFour a) {
return new ModFour((val+a.val)%4);

}

public String toString() { return "" + val; }

}

public class TwoOrThree extends ModFour {
TwoOrThree(int i) {

super(i);

if (i < 2 || i > 3) throw new RuntimeException();
}

The *only* trouble anywhere in here is if you want to have methods which are mutator methods; that is, methods which modify the distinguished object in place. And yes, in that case, closure is an issue. I have not seen any math books that give functions the same semantics as inherited OOPL mutator methods however.

Also, I found this equation in a math book on page 3:

Marshall Received on Fri Oct 20 2006 - 00:33:15 CEST