Re: Mixing OO and DB

On Thu, 21 Feb 2008 19:30:55 -0800 (PST), David BL wrote:

> On Feb 21, 8:31 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> wrote:

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

All types which can be derived from String.

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

It was your point, that values are mathematical entities rather than ones dealt with the types system. In my view the latter are proper values and the former could be meanings (in case of a numerical application).

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

Well, but you have to presume some abstract computational machine instead. It is OK to abstract hardware, but that does not mean that you could completely get rid of it. Instead, you could use, say, Zermelo-Frenkel set theory as a hardware, when talking about mathematical constructs.

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

A set of types is not a type.

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

It is OK to use an abstract implementation. The point is merely that there would be no way to deal with encoding if you considered it abstracted away. This moves the problem to the hardware's side. This is what I don't want, because then in order to describe that hardware, you will need yet *another* theory of types and values.

Now, there is a difficult choice before you:

1. You don't have such a theory and thus propose to develop hardware in assembler.
2. You have it. Then let's talk about that.

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

The proof is the "code".

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

Consider the type system as a DBMS which operates on some "data", which are values and types. This gives us an opportunity to treat as a value anything we wanted. You could take a mathematical integer or a bits octet.

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

Well, this a philosophical question. A constructivist would reject this.

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

Yes, and this is an interesting part. I do think that many problems of contemporary languages are rooted in wrong mental models. I think that so-called competing paradigms like OO, RA, FP are rather aberrations caused by lack of clear view on the issue.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de