Re: Mixing OO and DB
Date: Tue, 19 Feb 2008 17:49:57 -0800 (PST)
Message-ID: <3391b1c5-5e0b-4909-8fae-e378c3032575_at_u10g2000prn.googlegroups.com>
On Feb 19, 6:42 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
wrote:
> On Mon, 18 Feb 2008 17:44:58 -0800 (PST), David BL wrote:
> > On Feb 19, 12:41 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> > wrote:
> > Think of it this way... A string class defines both
>
> > 1) an interface (with well defined contracts on the operators); and
>
> > 2) an implementation (which defines both a physical representation as
> > well as an implementation of all the operators that fullfills the
> > documented interface).
>
> > Do you agree that it is meaningful to think of these aspects as
> > distinct, and somewhat independent?
>
> Yes. Moreover this implies that we have to keep the values of the kinds 1
> and 2 distinct. The values of the kind 1 are abstract strings, it can be
> any concrete implementation of string. They are said polymorphic. The
> values of the kind 2 are ones of a specific string type. When we talk about
> a string value we have to decide is it 1 or 2 (that implements 1).
I disagree that there are distinct kinds of values. In this example there are only abstract string values.
> > For example, assuming design by
> > contract it is possible to change the implementation without changing
> > the interface.
>
> Yes. Precisely it means that you can program things in the terms of the
> kind 1 and substitute any kind 2 when you will.
Just to clarify - you can substitute one implementation of strings for a different implementation. It doesn't make sense to say that you substitute an implementation for an interface.
> > You seem to be thinking type = class,
>
> No. To me class is a set of types. For some classes, like those built upon
> derivation, there exist special types of polymorphic values.
Are you overloading the word class?
> > 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")
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. 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.
[snip]
> >>> 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).
This has nothing to do with whether the abstract value 1 can be deemed both an integer and a real number at the same time.
However, we don't even agree on what "value" means, so it's not surprising we will have many differences of opinion.
[snip]
> > 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
> 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?
> >>>> Note that this is same as in mathematics where Q
> >>>> "contains" Z, while members of Q aren't numbers at all, but sets of ordered
> >>>> pairs
>
> >>> Z is only uniquely defined up to isomorphism. I think that explains
> >>> why Q can be defined as sets of ordered pairs and yet contains Z.
>
> >> So what is wrong with handling values this way? Why isomorphism of little
> >> endian to big endian numbers is worse? Why do you want to have some other
> >> level behind it? My approach looks much simpler.
>
> > I'm not sure what you are saying - you need to elaborate.
>
> 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. In your example it could be the abstract set of unsigned integers 0,..,65535, plus the modulo 2^16 operations on them. There happen to be two alternative representations (ie ways to encode values of this type). You seem to confuse the encoding of a value with the value being encoded.
I prefer to think in terms of an isomorphism between a type and a particular implementation of the type. Of course isomorphism is transitive so you are correct that there will be isomorphisms between the alternative implementations.
I don't accept that your approach is simpler. In fact your approach doesn't provide any clues about how logical-physical independence is achieved.
> >>> 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.
What happened to design by contract? Received on Wed Feb 20 2008 - 02:49:57 CET