Re: Mixing OO and DB

On Feb 21, 8:31 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de> wrote:
> On Wed, 20 Feb 2008 21:14:20 -0800 (PST), David BL wrote:
> > 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.
>
> C++'s class String introduces:
>
> 1. A specific type String
>
> 2. A class of types derived from String

In (2) are these the types that happen to derive from String at a given time?

> >>> 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?
>
> >> 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.

You're saying the (abstract) values and types don't exist in the types system?

> >> 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?
>
> I don't know what you call "abstract."

I say values and types are abstract in the sense that they aren't tied to the computational machine. They are mathematical constructs, if you like.

> In C++ an abstract class is a type which may not have objects. This does
> not mean that the class rooted in it may not have them. Neither it means
> that its specific type may not have values.
>
> A pure interface would be a better example. Interfaces have a class, but
> they don't have the specific type and thus no specific values.

All value types have a well defined set of values.

> >>>>>>> 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.
>
> Yes.
>
> > 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.
>
> We need a framework to express these "encodings." I don't see any in your
> proposal.

Well I'm tending to talk (only) about the type system. You are instead talking about how types are implemented.

> I treat them different values in order to be able to deal with them. A type
> of big endian values *models* Z. They are distinct, especially because it
> can be easily shown that no equivalence may exist. Encoding is merely a
> mapping from big endian to Z.
>
> > Are you suggesting that a type cannot be defined mathematically (and
> > independently of a physical implementation), or that an isomorphism
> > cannot be established?
>
> Yes, certainly.

Huh? That didn't answer the question which was for you two pick amongst two options (or both if you like).

> Note that under "physical implementation" I understand a
> formal system. When you say "mathematically" you imply such a system, where
> Z, for example is constructed. In that system Z has an implementation. You
> cannot abstract it.

I don't understand you. Z can be defined mathematically, proven unique up to isomorphism (but not proven to be self consistent) without writing a single line of code.

> >>>> 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?
>
> You have to describe, for instance IEEE floats in order to be able to use
> them. IEEE floats have very little to do with R. Yes it is possible and
> necessary to describe them mathematically, but how are you going to say
> that they can be used in place of R? They aren't R. This is all no matter
> to me, because I don't claim them same, I just establish mappings and
> *describe* differences. But this is only beginning. What will you do with
> composite types, like records, pointers, tasks, rendering contexts etc? You
> will need to invent some imaginary "true" mathematical values for all of
> them.

Well in OO systems you quickly get into object types that don't represent values. For the value types we assume in principle that the mathematical set of values is well defined, even if we haven't bothered to define it. Of course there is nothing wrong with defining the mathematical set of values in terms of a binary encoding if it makes sense (such as with IEEE floats). I'm just saying that the type as an abstract set of values isn't conceptually identified with a particular encoding, even if it seems clear that one is canonical.

> >>> 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.
>
> No.
>
> 1. In that case, the "hardware" is the corresponding set of axioms, like an
> axiomatic set theory.
>
> 2. The types system as I understand it, does not define concrete types and
> values. It is an algebra where you can construct new types or deal with
> existing ones. The difference is like between DB and DBMS.

I don't understand that.

> > 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.
>
> Sorry for that, but programs have to be executed on real hardware. Any
> separation is fictional.

But the value type system doesn't execute. It just "is".

> The language should provide the programmer tools
> and means for encapsulation and information hiding. That does not mean that
> this should make it *fundamentally* impossible to implement integer
> arithmetic, just because that might be used in order to model Z. Looks like
> an utterly scholastic argument to me.

Our differences of opinion seem to lead to a huge impact on language design. Received on Fri Feb 22 2008 - 04:30:55 CET