Re: Mixing OO and DB

From: Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de>
Date: Wed, 20 Feb 2008 11:45:44 +0100
Message-ID: <10zkvw1lm5u6k$.15jxnouhrj6h7.dlg_at_40tude.net>


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.

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

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

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

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

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

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

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Received on Wed Feb 20 2008 - 11:45:44 CET

Original text of this message