Re: Mixing OO and DB
Date: Thu, 21 Feb 2008 05:41:42 -0800 (PST)
Message-ID: <8609bb61-4d4d-407b-8c45-91bef018f91b_at_h11g2000prf.googlegroups.com>
On Feb 21, 9:11 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
wrote:
> On Wed, 20 Feb 2008 21:42:44 -0800 (PST), David BL wrote:
> > On Feb 20, 8:05 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> > wrote:
> >> On Tue, 19 Feb 2008 18:15:31 -0800 (PST), David BL wrote:
> >>> On Feb 19, 7:05 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> >>> wrote:
> >>>> On Mon, 18 Feb 2008 19:09:48 -0800 (PST), David BL wrote:
> >>>>> On Feb 19, 12:41 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> >>>>> wrote:
> >>>>>> On Mon, 18 Feb 2008 05:59:39 -0800 (PST), David BL wrote:
> >>>>>>> I disagree. I'm talking about algorithms that are implicitly
> >>>>>>> parameterised over various value-types. LSP isn't even applicable for
> >>>>>>> value-types.
>> >>>>>> predicates. This clearly includes your parametrized types. The parameters
> >>>>>> How so? LSP defines behavioral notion of type as set of provable
> >>>>>> are subjects of type substitution. It is pure LSP.
>> >>>>> variable that has identity, state and behavior, but isn't assumed to
> >>>>> I have a more specific understanding of LSP. Let an object mean a
> >>>>> hold a value.
>> >>>> semantics is fundamental in the sense that a stateful one is derived from
> >>>> Wait here. Object's state + identity = its value. As I said before, value
> >>>> it.
>
> >>> Saying
>> >>> following a pointer? What about objects with OS resource handles
> >>> Object's state + identity = its value
>
> >>> doesn't seem well defined. Does the object's state ever encompass
> >>> like socket handles or mutex handles? How do you delineate its state?
>
> >> Resource value /= value of its handle. They are of *different* types.
>> >> correct. Claiming the equivalence in advance is putting a cart before the
> >> (You have a mental block about [fictional] equivalences of values. Whatever
> >> equivalence between the resource and its handle might exist, it is not an
> >> immanent thing. It is simply an implementation to be *first* proven to be
> >> horse.)
>
> > You didn't answer my question. How do you define an object's state
> > when it contains pointers or handles?
>
> Through the values of those pointers and handles. Where is a problem?
>
> > Here's an example
>> > };
> > class X
> > {
> > public:
> > X() { p = new int(0); }
> > ~X() { delete p; }
> > int Get() const { return *p; }
> > void Set(int x) { *p = x; }
> > private:
> > int* p;
>
> And? Did you mean X could be made a subtype (and supertype) of int. So
> what?
No. Please ignore the purpose of X. However assume that its copy constructor and assignment operator have been declared private to make it clear that it isn't a value type.
How do you justify that? It seems entirely adhoc to me.
> >>>> Right, this is exactly what you said above "subtyping can mean
> >>>> anything you want it to mean." It is not the compiler's business.
>> >>> substitutability? Whatever the rules are, surely they are well
> >>> Can you define precisely what rules the compiler uses for
> >>> defined?
>
> >> Yes. There rules are two:
>
> >> 1. It is typed: the value has to have the type expected.
>
> >> 2. S is a subtype of T in the operation f, if both types have this
> >> operation defined.
>
> > I thought we agreed type = set of values + operations. What does it
> > mean to say an operation is defined?
>
> It means that the type has this operation. Again subtyping is a relation to
> me. If + is defined on both T and S, then they are subtypes of each other.
> >>>>> You are saying there is no difference in C.Date's notion of sub-
> >>>>> typing, versus a definition of subtyping that allows you to substitute
> >>>>> the type in a parameterisation. I cannot understand that.
>> >>>> Date's subtype Z is R - Invert. He disallowed this operation. In some
> >>>> We agree that type = values + operations. When we substitute a type, we do
> >>>> its operations as well (where covariant). A simple consequence is that Z
> >>>> which does not have Invert cannot be substituted where Invert operation is
> >>>> expected. The notion of subtype is still same in the sense of conversions.
> >>>> contexts it will go, in others it will not.
>> >>> He states very clearly that a subtype always has a *superset* of the
> >>> On the contrary, Date assumes that Z inherits real-valued
> >>> multiplicative inverses from R. He doesn't disallow any operations.
> >>> supertype's operations.
>
> >> This is sloppy. Remember that Invert is defined as:
>
> >> Invert : T -> T
>> >> a field. In effect the field's Invert is disallowed. The case is very
> >> When you say "inherit" you have to clarify where Z gets substituted. If you
> >> substitute it only under the first T it is not an inheritance required for
> >> clear.
>
> > C.Date made it very clear that subtyping (only) allows for value
> > substitutability. I found nothing sloppy in his exposition.
>
> Sloppiness is that this ignores other [useful] forms of substitution.
Being specific is not sloppy! It just means that additional language features may be needed.
> 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.
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! 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.
> Note that I don't buy parametrization for two reasons:
>
> 1. It is a meta language (=accepted defeat)
>
> 2. If parametrization were OK, then why did you introduce
> in-substitutability? Let's kill it too and use parametrization everywhere.
I don't accept your second reason because in-substitutability avoids a lot of parameterisation so that's a positive not a negative.
// Field = set of types
type* Field;
type Complex
in Field
...
{
};
type Real
in Field
...
isa Complex
{
type* Ring;
type Integer
in Ring
isa Real
{
...
};
Since we haven't been able to avoid parameterisation of Matrix, 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. Received on Thu Feb 21 2008 - 14:41:42 CET