Re: Mixing OO and DB

From: David BL <davidbl_at_iinet.net.au>
Date: Wed, 20 Feb 2008 21:14:20 -0800 (PST)
Message-ID: <6f6113a4-23fb-447a-93b3-502700a5fcc7_at_e10g2000prf.googlegroups.com>


On Feb 20, 7:45 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de> wrote:
> On Tue, 19 Feb 2008 17:49:57 -0800 (PST), David BL wrote:
> > Are you overloading the word class?
>
> No, to me class is a set of types.

When I said "String class" I meant a class as understood by a C++ programmer - ie something that introduces both a type as well as an implementation of that type. Now you are using "class" for something else, which is potentially confusing.

> >>> 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.
>
> Any set of types is a class.
>
> > I find your descriptions mechanistic (saying what not why). You
> > haven't given me the intuition behind them. Some realistic examples
> > might help.
>
> What was wrong with the example of strings?
>
> > 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.
>
> How are going to have "unimplemented values"?

I think you missed the point. A value-type by definition is abstract. Are you trying to prove that nothing can be abstract?

> > 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.
>
> In that case we are talking about different things. The abstract values
> and types are of no interest as they do not exist in the formal system.

What formal system are you referring to?

> The
> types system operates only existing = concrete values and types. They might
> have some abstract meaning outside the system, but that is of no matter to
> me.

I can't imagine what you possibly mean by trying to distinguish concrete versus abstract values, or concrete versus abstract types.

Types and values are always abstract.

You can for example, distinguish between abstract and concrete C++ classes. See the difference?

> >>>>> 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.
>
> I don't understand this argument. What is encoding? Why should it matter?
> By which means can you describe encodings? How to handle encodings? It just
> makes no sense.

You said yourself that a value isn't part of the computational machine. Instead variables are. Variables hold an "appearance" or an "encoding" of a value. Most generally a given value can be encoded in different ways.

The choice between little/big endian (only) has to do with alternative encodings of the same value.

> >>> 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.
>
> I don't see how you could do this in your system. It looks hopeless.

Are you suggesting that a type cannot be defined mathematically (and independently of a physical implementation), or that an isomorphism cannot be established?

> >> 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?
>
> You are going to define it once and for all.

What do you mean?

> >> 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.
>
> So I conclude that you cannot describe / handle endianness (or whatever
> representations) in your types system. Which was all the point.

Exactly. The type system can be defined mathematically and independently of any implementation.

> >>>>> 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!
>
> No, I say that there is no meaning of subtyping. Subtyping is a relation
> between types. Full stop.
>
> > What happened to design by contract?
>
> Contract /= meaning. Contract is a set of well-defined predicates to be
> true. It cannot capture "meaning".

I don't consider the word "meaning" to be formal. My problem is that during design a programmer will interpret subtyping according to whatever rules of substitutability it entails, and you are saying that those rules depends on implementation details, not on the mathematical definitions of abstract value types. Therefore you have ruined the logical-physical separation. The type hierarchy is no longer independent of how types are physically implemented. Received on Thu Feb 21 2008 - 06:14:20 CET

Original text of this message