Re: Mixing OO and DB

From: Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de>
Date: Thu, 21 Feb 2008 12:31:02 +0100
Message-ID: <hzljnw5vwx54.82xq75eypadf.dlg_at_40tude.net>


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

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

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

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.

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

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

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

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Received on Thu Feb 21 2008 - 12:31:02 CET

Original text of this message