Re: Mixing OO and DB

From: Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de>
Date: Fri, 22 Feb 2008 12:20:40 +0100
Message-ID: <1kqbcr826thny$.1o3ov8xcf9910.dlg_at_40tude.net>


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

> On Feb 22, 4:04 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de> > wrote:

>> On Thu, 21 Feb 2008 05:41:42 -0800 (PST), David BL wrote:
>> It is not very clear to me what does require a justification. There is no
>> relation between X, int, int* except than stated. X has values. Note that
>> values are incomparable (as it should follow from what I said before).
>> Hence you could not say that two X are same if p is same. If we liked the
>> compiler to copy X, we would declare corresponding copy operations. That
>> would make possible by-copy parameter passing. But again it would not
>> guarantee anything like "same value passed". The compiler would apply the
>> copy operation, get a value and whether that is same is up to the
>> programmer. In short, two values are same when the operation = is defined
>> and returns true. Otherwise, nobody cares.

> 
> I see no point in thinking an object represents a value that combines
> its identity and state.

The point is, I don't need a separate notion of state and identity. So I have only one subtyping / inheritance model.

> It is a function of its implementation.

Why then do you want to introduce them, if you cannot even say anything about them before you have programmed the object? What does abstract what?

>>>> I
>>>> hope you aren't going discard the notion of field? Then how to capture it
>>>> without out-substitutability?
>>
>>> Out-substitutability isn't enough either. Algorithms and data
>>> structures that are parameterised in a field T may mention T in many
>>> places. For example, in variables declared on the frame within a
>>> function, or for members of data structures etc.
>>
>> You should care only of field operations.
>>
>>> I think it is utterly wrong to say that Real and Complex are subtypes
>>> of Field. In fact I would suggest that it's rather confusing to think
>>> of Field as a type at all!
>>
>> Sure, because field is a class, a set of types implementing the interface
>> of. Note that class is not a type. A class can have an associated type of
>> its polymorphic values when that makes sense. In the case of Real and
>> Complex it does. I.e, there could be a subclass of field containing Real
>> and Complex in order to be able to mix them in arithmetic. In general case
>> for Field it does not make sense. It could be sort of:
>>
>> Field <-- Numeric field <--- Real / Complex
>>
>>> As we've agreed a type is a set of values
>>> plus a set of operations on those values. Do you see how Field
>>> doesn't fit that notion very well? If we want to shoehorn it into
>>> being a type then its values are themselves types like Real and
>>> Complex. I cannot think of any operations on it.
>>
>> Field is not a type it is a set { Real, Complex } (for simplicity only
>> these two). The closure of Field is a proper type. Its values are pairs
>> type - value. It has all operations of the field, like +, -, *, ... These
>> operations are said dispatching (virtual in C++ terms). When + is applied
>> to the polymorphic values an operation is chosen according to the first
>> elements of the pairs involved and applied to the second elements of.

> 
> If you want a union type then it seems better to use an explicit
> supertype as per C.Date.  In fact doing so makes it clear that the tag
> may not even be necessary - as when we want a common supertype of both
> Complex and Real, because Complex already serves that purpose if Real
> subtypes Complex.

Tag is always necessary as it has to be typed. But if the type is statically known, then tag can be removed from the representation.

But anyway, this means that the values of the supertype have to keep the imaginary component even if they are in fact reals and used as reals. This is the price to pay for illusions!

(If we considered a vector space you would use vectors instead of reals. God-objects again?)

>> This is a different issue, namely, how containers are created in the types
>> algebra. I would not like to see parametrization here. Instead it should
>> state (without inventing some ad-hoc syntax):
>>
>> 1. Matrix is an interface
>> 2. Matrix implements a container interface of a two dimensional array
>> 3. The container elements are from the class of Field.
>> 4. Matrix (square one) implements the ring interface
>>
>> Instead of parametrization Matrix could be constrained:
>>
>> 2.a in its indices (matrix size and shape)
>> 3.a in its elements (real matrix, for instance)
>>
>>> I
>>> don't think a lot has been achieved. Note as well that we didn't
>>> actually formalise what a field is apart from stating that Real and
>>> Complex are examples of fields.
>>
>> We did, when we declared Field. That shall have +, -, *, / etc. Real and
>> Complex have to implement them. Matrix will use these operations in order
>> to implement its own interface.

> 
> I think there is a danger that you will create a lot of effort for
> yourself (ie on top of a simple parameterisation approach).

I don't see how "simple" parametrization approach could work. How would you multiply Matrix<Real> by Matrix<Complex>?

To put it short parametrization, a.k.a. macros solves nothing when the results of macro expansions are unrelated types. If they are related, then you are back into the reality, which is - you need a vehicle to describe types relations.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Received on Fri Feb 22 2008 - 12:20:40 CET

Original text of this message