Re: Mixing OO and DB

On Fri, 22 Feb 2008 20:15:36 -0800 (PST), David BL wrote:

> On Feb 23, 3:04 am, Robert Martin <uncle..._at_objectmentor.com> wrote:

>> On 2008-02-21 20:43:52 -0600, David BL <davi..._at_iinet.net.au> said:
>>
>>> On Feb 22, 4:03 am, Robert Martin <uncle..._at_objectmentor.com> wrote:
>>>> On 2008-02-20 20:27:28 -0600, David BL <davi..._at_iinet.net.au> said:

>> I don't know Date's nomenclature.

Not quite. Triplet is still a mathematical construct as much as the set on the right side. The model ("circle value") is a thing of the type system. It might have similar denotation (like a tuple), or some different one, but this is other world, the solution space. It is necessarily different because already R cannot be spelt in the space.

> Taking this further, on computers we need a way to encode numbers and
> have to give up on any idea of being able to represent all the reals,
> so we only represent some subset - say by using an IEEE encoding. In
> this case we can talk about a function that maps an IEEE encoding to
> an element of the reals. This map isn't surjective.
>
> Now so far in the above I have avoided using the word "value".
> However I regard that word as being associated with each and every of
> the above abstract mathematical "things". Each real number is a
> value, each circle is a value, a triplet is a value, a bijection is a
> value, a set of triplets is a value and so on. For me the term
> "value" is independent of any particular *appearance* (ie encoding) of
> a value that may appear in computer memory or whatever.

Certainly you can have different models of the same thing. This does not make the models same. What you call "appearance", "encoding" etc, we call "value" on the model side. I have no problem with calling 1 a value of the side of R too, though it would be superfluous.

Important to us is to distinguish the model-of-R with its values and R-itself with its elements (values if you want).

> It is also worth saying what cannot be called a value. A human isn't
> a value because it isn't mathematically defined. Neither is a
> computer and therefore a variable associated with a specified region
> of computer memory. All of these occur in time and space. Therefore
> they are not values. Please take this as a definitional matter.

Why? What is wrong in considering a "human value"? The state of the universe which includes all humans can be described by some finite set. At least materialists believe in that. I don't believe it, but that's no matter. If a finite set were too small, let's take aleph 0, 1, 2... In some set there, one could definitely find an element for each human. Call it value.

> In the context of OO I would qualify that by pointing out that some
> people may say that a variable has state but doesn't necessarily
> represent a value. A mutex variable is an example. However, in this
> discussion about value types, C.Date's definition seems quite useful.

Same with mutexes. It is a value. The difference is that mutex, real-time clock, random generator, ADC register, task, human etc have incomputable values. So what? Practically all reals are incomputable. It is just no matter, you don't need to compute mutex value from bits.

> So to summarise: we distinguish between variables and values.
> Variables can "hold" values and be assigned

There exist variables that cannot be assigned, singleton for instance. Assignment is an operation which might be defined or not.

> Using Marshall's example
>
> int p = 5;
>
> p denotes a variable that holds the value 5.
>
> In the following
>
> Circle c( Point(0,0), 10 );
>
> c denotes a variable that holds a particular circle value. The circle
> value is exactly the circle of radius 10 and centre (0,0) which is
> well defined as a set of points in RxR. There is no ambiguity in
> which circle value the variable holds, and that is all that matters
> when formalising the mapping from the real machine to the abstract
> machine.
>
> Saying that c is a model of a circle is just gibberish.

Nobody says this. The model is the value c holds. The value of c is a model for the corresponding circle.

(The variable c serves a model for some set of circles. Like: the circle I am iterating through, right now.)

>> However the fact that I put two
>> variables next to each other, and call one "radius", and the other
>> "center", and then I wrap both in a container labled "circle", does not
>> mean I have a circle.

No. There result is a container value, a tuple. It is not a variable. Any type is a set of values + operations. Container is a type. The values of any type can serve models for geometrical figures. You are free in your implementation in that respect. For example, you can have special rendering hardware where circles would be referenced by some commands sent at a definite hardware address. In that case the type will use pointers and commands.

>> I cannot
>> roll that container the way I could role a circle.  I cannot use a tape
>> measure to empirically measure the circumference.  I cannot arrange
>> little tiny squares within it to approximate the area.  I cannot draw
>> the container with a compass, nor can I bisect it and measure the
>> internal angle of the bisection at a right angle.  The container, for
>> all it's wonderful ability to *describe* a circle, is not a circle.
>> And so that poor container is not a subtype of a similar container that
>> happens to describe an ellipse.

No. The difference is between the problem (geometry) and the solution spaces (program/model).

This has nothing to do with mutability. The only reason why mutability plays a sufficient role in the solution space is because the computational models are very weak. Mutability is used to overcome these constraints.

>> But the value is not a circle.  The value *refers* to a circle.

Variable refers to a value, the value does to a circle.

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