Re: Mixing OO and DB

From: David BL <davidbl_at_iinet.net.au>
Date: Tue, 19 Feb 2008 17:49:57 -0800 (PST)
Message-ID: <3391b1c5-5e0b-4909-8fae-e378c3032575_at_u10g2000prn.googlegroups.com>


On Feb 19, 6:42 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de> wrote:
> On Mon, 18 Feb 2008 17:44:58 -0800 (PST), David BL wrote:
> > On Feb 19, 12:41 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> > wrote:

> > Think of it this way... A string class defines both
>
> > 1) an interface (with well defined contracts on the operators); and
>
> > 2) an implementation (which defines both a physical representation as
> > well as an implementation of all the operators that fullfills the
> > documented interface).
>
> > Do you agree that it is meaningful to think of these aspects as
> > distinct, and somewhat independent?
>
> Yes. Moreover this implies that we have to keep the values of the kinds 1
> and 2 distinct. The values of the kind 1 are abstract strings, it can be
> any concrete implementation of string. They are said polymorphic. The
> values of the kind 2 are ones of a specific string type. When we talk about
> a string value we have to decide is it 1 or 2 (that implements 1).

I disagree that there are distinct kinds of values. In this example there are only abstract string values.

> > For example, assuming design by
> > contract it is possible to change the implementation without changing
> > the interface.
>
> Yes. Precisely it means that you can program things in the terms of the
> kind 1 and substitute any kind 2 when you will.

Just to clarify - you can substitute one implementation of strings for a different implementation. It doesn't make sense to say that you substitute an implementation for an interface.

> > You seem to be thinking type = class,
>
> No. To me class is a set of types. For some classes, like those built upon
> derivation, there exist special types of polymorphic values.

Are you overloading the word class?

> > whereas I'm thinking of type as
> > by definition only relating to the public interface. More formally a
> > value type is a set of values plus operations on those values.
>
> Yes, of course.
>
> > It is
> > divorced from a particular implementation.
>
> No. Each type has an implementation and this implementation is concrete. It
> only appears that you can change implementation. Substitution is a vehicle
> for. You substitute a string for its class. Both have implementations. BTw,
> when you substitute for a class, you convert its value:
>
> "abcd" --> (Four_Characters_UF8_Encoded_String, "abcd")

I'm struggling to know what you're talking about. We don't even seem to agree on what a value is.

You defined class in terms of the type hierarchy without defining what a subtype means. Since I don't know what you mean by subtype I don't know what you mean by class.

I find your descriptions mechanistic (saying what not why). You haven't given me the intuition behind them. Some realistic examples might help.

You agree that a type is by definition only relating to the public interface, and then seem to say each type has one concrete implementation. I can't reconcile that. For a start it implies all types are concrete. I also can't reconcile with saying type = set of values + operations. Values are by definition abstract. Therefore a type is as well. ie a type is divorced from any particular implementation.

[snip]

> >>> Are you suggesting there can be any number of levels of equivalence
> >>> classes at ever increasing logical levels?
>
> >> Why not?
>
> > A value-type is by definition a set of values plus operators on those
> > values. There can only be one concept of equivalence for a given
> > value-type.
>
> Ugh, isn't 1 real, integer, complex, file descriptor number, character... I
> don't want to define equivalences in the language, it is the programmer's
> business. Formally, you can take some specific type with its values and put
> it in whatever class (by implementing the corresponding interface).

You have agreed that a type is a set of values + operations. This *implies* that for a given type there can only be one definition of equivalence of encoded values.

For example, if type = (Z,+,*) then you have no choice but to say all encodings of 1 are equal to each other, and are distinct from all encodings of 2.

This has nothing to do with whether the abstract value 1 can be deemed both an integer and a real number at the same time.

However, we don't even agree on what "value" means, so it's not surprising we will have many differences of opinion.

[snip]

> > Yes there will be built in value types. Eg 32 bit integers. These
> > have well defined semantics. All the programmer needs to know is that
> > they map very directly and efficiently to the hardware. Little
> > versus big endian encoding is irrelevant to the logical level semantic
> > of the type.
>
> As for modular types:
>
> 1. may I have one of modulus 2**100000000000000000?
>
> 2. how to write a (one) program which reads a modular integer value from
> the keyboard?
>
> 3. note that "well defined semantics" contradicts to very definition of
> type:
>
> type = values + operations

I guess that depends on what is meant by semantics. I meant that the type can be defined mathematically, and the physical implementation has to embody it. This can be formalised with an isomorphism.

> So any subprogram taking a type value as a parameter is an operation => you
> cannot define semantics well. The only definition could be "all possible
> programs with the values of."

> > Why do you think built-in value types are a problem? I believe they
> > should be treated like any other type, apart from a user defined
> > implementation being optional. For example, built-in types should
> > take part in the type hierarchies.
>
> Huh, what about integers, floats, fixed point? The semantics of those is
> *far* from being simple.

So?

> >>>> Note that this is same as in mathematics where Q
> >>>> "contains" Z, while members of Q aren't numbers at all, but sets of ordered
> >>>> pairs
>
> >>> Z is only uniquely defined up to isomorphism. I think that explains
> >>> why Q can be defined as sets of ordered pairs and yet contains Z.
>
> >> So what is wrong with handling values this way? Why isomorphism of little
> >> endian to big endian numbers is worse? Why do you want to have some other
> >> level behind it? My approach looks much simpler.
>
> > I'm not sure what you are saying - you need to elaborate.
>
> Let have two types IntBig and IntLittle. There is an isomorphism between
> the values of. If the compiler would apply it I could substitute one for
> another.

I don't accept that terminology. There is only one type. In your example it could be the abstract set of unsigned integers 0,..,65535, plus the modulo 2^16 operations on them. There happen to be two alternative representations (ie ways to encode values of this type). You seem to confuse the encoding of a value with the value being encoded.

I prefer to think in terms of an isomorphism between a type and a particular implementation of the type. Of course isomorphism is transitive so you are correct that there will be isomorphisms between the alternative implementations.

I don't accept that your approach is simpler. In fact your approach doesn't provide any clues about how logical-physical independence is achieved.

> >>> I'm afraid this gives me more questions than answers! I don't know
> >>> what a Boolean actually is. Can it have 3 states?
>
> >> No, Boolean is defined over {0, 1}. Tristate is derived from it and is
> >> defined over {0, 1, _|_}
>
> > I don't understand the semantics of sub-typing in this case. Can a
> > TriState value be implicit converted to a Boolean value? If so what
> > happens when it's in the unknown state?
>
> It cannot be. It is only out-substitutable. That means for example that
> Image has to be overridden. If inherited it will break the contract.
>
> The compiler can immediately detect this, provided that Tristate would not
> inherit Boolean's implementation. There will be no default conversion
> Tristate -> Boolean, so the compiler will not be able to compose an
> inherited Image out of Boolean's Image and the type conversion. So it will
> complain. Note this is absolutely free on any black magic logical-values
> stuff. The compiler need not to know the semantics of Boolean in order to
> decide that.

You're saying that the logical meaning of the subtyping is buried in the implementation of the methods!

What happened to design by contract? Received on Wed Feb 20 2008 - 02:49:57 CET

Original text of this message