Re: Natural keys vs Aritficial Keys

On May 28, 12:25 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:

> It is less clear that it is a blunder when associating a class (which is a
> type) with a relation scheme, which is not a variable, but rather very much
> like a type (at least under the specialization by constraint paradigm). The
> set of constraints that defines the set of all possible relations indirectly
> defines the set of all possible tuples. Why, then, should it be wrong to
> map object instances to tuples?

As I said, there is nothing implicitly wrong with a tuple-variable that binds to a /specific/ tuple-value (rather than an /unspecified/ one taken from some given relvar).

The ORM idea makes the blunder because it assumes incorrectly that the values within a set can be identified independently of their value. ORM wants to make this assumption so that a variable that records a set of values can instead be interpreted as a set of variables.

I find the concept of a "sub-variable" of a given variable interesting. For example, given a tuple-variable, there are subvariables  for each of the attributes. However with other ways of composing data structures, sub-variables may not exist. A relvar is one such example.

One aspect of the idea of sub-variables that interests me is the concept of in-place editing of data, which means there exists a defined mapping of the data structures to a representation on the screen that can be edited directly with mouse and keyboard - i.e. without the need for 'transactional editing' such as through the use of dialogs that involve editing of temporary variables. For example, it doesn't appear realistic to in-place edit a set of integers, whereas it is possible to in-place edit an ordered list of integers. This interests me because I like the idea of applications that promote in-place editing of complex data.

> I don't think object instances are variables.

C.Date defines a variable as something that exists in time and space and "holds" or "encodes" a value.

The conventional OO concept of 'object instance' requires amongst other things than an object exists at some specific address in memory, giving it identity and state in the context of the computational machine in which it appears. This oversimplifies because it prejudices against techniques like distributed objects, virtual memory, swizzling, copying garbage collection etc, but that is not relevant to this discussion.

Assuming these definitions some object instances are variables and some aren't.

For example an object instance of class String is a variable. However an object instance of class Mutex is not.

Some OO programmers refer to a String class as a "value type", whereas a Mutex class has more to do with defining a type of Finite State Machine (FSM). However being a FSM is not a defining characteristic of objects that are not variables because any variable can be regarded as a very simple FSM (that changes its state through assignment).

Like all variables, all object instances exist in time and space and have state. However objects don't necessarily "hold a value" which is the defining characteristic of a variable. A Mutex is a good example, because its state cannot be interpreted outside of the context of computational machine it takes part in.

I actually think a good starting point for an abstract definition of "object instance" is that it is an identifiable FSM within a larger abstract computational machine.

I once posted to this ng, stating that I think OO only makes sense when objects are "part of the abstract machine", and don't pretend to map to entities outside the abstract machine. The thread had several hundred posts and I was hammered by multiple adversaries who seemed overly intent on metaphysics. The wounds still run deep :-). My point of view hasn't changed at all, but after studying C.Date and reading this ng for some time I'm now much better able to express myself.

Examples of sensible OO classes are

    String, Queue, Stack, Relation, Thread, ThreadPool, Mutex,     PrinterProxy, Window, Button

whereas silly examples are

    Employee, Company, Department, Teacher, Supplier.

Some authors actually teach OO using the latter not the former. In my opinion any such author probably hasn't got a clue about the nature and purpose of OO (which is basically to construct a complex FSM from simpler ones). What has a class called "Employee" got to do with that? At best an object instance of an Employee class would be a tuple-variable that records a tuple-value. It would follow that the identity of the variable has absolutely nothing to do with the identity of the human that the tuple currently happens to reference through the values of the attributes. It would also follow that encapsulation as an ADT is inappropriate. A variable by definition supports assignment to all possible values of its type. In particular, a tuple-variable must support unconstrained read/write access to all of its members.

The stupidity of this misuse of OO becomes evident where there are rules like "never allow two distinct object instances to represent the same employee", or its corollary "never clone an employee object". Those rules could only make sense if the model of the thing /is/ the thing, which of course is exactly the lie implicit in these ridiculous class names.

That's before getting into the really dumb idea that these tuple-types would form inheritance hierarchies (such as a SalesEmployee that inherits from Employee) - which is about as stupid as making a 3D point inherit from a 2D point (or as Date says, where a coloured rectangle inherits from rectangle).

My background could best be described as a systems programmer and I'm interested in things like heaps, threads, stacks and OO is quite useful for that. I think the ORM idea, or indeed the very idea of modelling real world entities like employees using OO classes is bizarre. Received on Thu May 28 2009 - 08:45:51 CEST