Re: Objects and Relations

On Feb 5, 4:35 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
> On Feb 5, 7:25 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
>
>
> > On Feb 5, 6:40 pm, "JOG" <j..._at_cs.nott.ac.uk> wrote:
>
> > > On Feb 5, 5:09 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
> > > > On Feb 3, 11:33 pm, "Walt" <wami..._at_verizon.net> wrote:
>
> > > > > "David BL" <davi..._at_iinet.net.au> wrote in message
>
> > > > > > Many of the wars between the OO and RM camps end up in side issues,
> > > > > > often with unsubstantiated performance or scalability claims or
> > > > > > discussions about whether physical independence is good or bad.
>
> > > > > > AFAIK these discussions ignore something simple and fundamental, which
> > > > > > I will describe in this post.
>
> > > > > > I have previously discussed this on comp.object (with mixed results),
> > > > > > and I'm interested in feedback from the relational camp.
>
> > > > > > Consider a web server. This can be seen at a number of different
> > > > > > "levels of abstraction"
>
> > > > > > 1. Elementary particles
> > > > > > 2. Atoms
> > > > > > 3. Molecules
> > > > > > 4. Electronic components
> > > > > > 5. Digital circuits
> > > > > > 6. Computer
> > > > > > 7. Executing process
> > > > > > 8. Abstract computational machine
> > > > > > 9. Web server
>
> > > > > > All of these "levels of abstraction" are equally valid. I don't want
> > > > > > to get into boring discussions about what's physical versus logical,
>
> > > > > I think I get what you're driving at with multiple "levels of abstraction",
> > > > > but before I get into the substance of your discussion, I want to react to
> > > > > your introduction.
>
> > > > > Layers 1 though 4 are too detailed for this discussion, and are a
> > > > > distraction. You can collapse them all into one big layer, the "analog
> > > > > layer", where digital signals are stored, transmitted, and manipulated
> > > > > using the Physics (and maybe Chemistry and Biology) of the underlying
> > > > > material world.
>
> > > > > The "digital circuits" layer is something many of us know only as "the layer
> > > > > below the last one we have studied". It deserves the mention you gave it.
>
> > > > > Between "computer" and "executing process", I would insert several layers
> > > > > of abstraction. Here are some possibilities, just off the top of my head:
>
> > > > > "Operating system" (Unix or Windows, etc.)
> > > > > "DBMS" (Oracle, DB2, etc.)
> > > > > "virtual machine" (like the Java virtual machine)
> > > > > "runtime environment" (different for various languages and for different
> > > > > implementations of some languages).
>
> > > > > And finally, "application object library". Essentially the "object world"
> > > > > in which all the application objects reside. It's not clear to me whether
> > > > > this layer is at a lower or higher level of abstraction than the executing
> > > > > process.
>
> > > > > As I said, this is off the top of my head. I'll probably change my mind
> > > > > later
>
> > > > My intention was merely to drive home the point that virtually all our
> > > > names for "real" objects around us can in fact be regarded as merely
> > > > abstractions. I have no problem calling a lump of physical matter a
> > > > "computer" one day and "garbage" the next when it is taken to the
> > > > rubbish tip. The way we interpret the world has as much to do with
> > > > our perception as any underlying reality (which might be strings or
> > > > branes in 10 or 11 spacetime dimensions according to string theorists,
> > > > but who knows?). I see no problem calling a collection of pixels
> > > > displayed on a touch screen (together with hardware/software that
> > > > allows it to function) a real "button".
>
> > > > You may well wonder why I went to the trouble to set this mindset. On
> > > > comp.object some people argued that the criterion of whether an object
> > > > represents itself wasn't meaningful because objects always represent
> > > > something else. For example, an instance in memory may represent a
> > > > pure mathematical abstraction like a "stack". On its face this is
> > > > quite true. However if an instance of a class called "stack" indeed
> > > > behaves like a mathematical stack at a certain level of abstraction
> > > > (in the abstract computational machine) then there is a sense in which
> > > > the instance is not pretending to be something else. Contrast this
> > > > to an Employee instance that claims to be a human. The difference is
> > > > that an actual human is not a part of the abstract machine. Actual
> > > > humans are complex, somewhat illogical entities that have no right to
> > > > be directly confused with objects in a running process.
>
> > > > Objects by definition must represent the proverbial "it". They must
> > > > be the "real deal". This is what object identity means. To screw
> > > > that up is to create lies in the program. I'm amazed that so many OO
> > > > programmers are happy to do this, even when it is pointed out to them.
>
> > > > BTW in the context of this thread, when I say "OO" I'm thinking
> > > > predominantly about how an instance of a data structure is thought to
> > > > encapsulate state, behavior and identity. I'm not particularly
> > > > characterizing OO by the presence of class hierarchies or by the use
> > > > of polymorphism.
>
> > > > It's my impression that a poor understanding of object identity leads
> > > > to designs with excessive class hierarchies. For example an Employee
> > > > class can be specialised in many ways, such as SalariedEmployee,
> > > > WagedEmployee, SalesEmployee. The fact of the matter is that
> > > > external entities like humans are often capable of countless
> > > > behaviors. Humans can be gardeners, psychopaths, circus performers,
> > > > parents, carnivores, mammals and so on (and often all at once). RM is
> > > > much better at stating factual information about humans without
> > > > pretending to actually represent one for real. The information about
> > > > a given human can and should be spread across lots of relations.
>
> > > First, In the outside world we only identify things by the values of
> > > the attributes they exhibit, and not by some omiscient OID.
>
> > I'm not sure I follow. I don't see anything innately wrong or
> > difficult with labelling external entities with unique identifiers. I
> > agree that entities don't generally come already labelled. Is that
> > what you mean?
>
> > > Second the
> > > 'things' and 'its' of which you speak are not absolute -
> > > interpretation of their scope varies from individual to individual,
> > > and their boundaries cross and blur. Trying to 'encapsulate' one is a
> > > fool's errand, as they don't really exist.
>
> > I'm not sure what you mean. Can you give me an example where it
> > matters that the scope of an external entity is subjective?
>
> > > So, Identity does not exist outside observable attributes, and
> > > symbolic entities do nothing but generate query bias at the logical
> > > layer.
>
> > I agree with the query bias but not your reason for it. For example,
> > I see no difficulty in assigning a label to a particular human. To
> > the extent that facts about that human will be recorded in a typical
> > RM application there is no confusion about the scope or boundary of
> > the human.
>
> > For me it is the problem with trying to record all conceivable
> > information about a human in a single data structure that is
> > problematic, and explains why OO has a hard time of it. I don't see
> > how labelling a human in itself has any difficulties. The problem
> > seems to have far more to do with type analysis (ie classifying
> > humans) in order to know what attributes need to be recorded. This
> > is the fool's errand.
>
> I think I am finally catching on to at least one of your points, and
> if I have, then I disagree with it.
>
> OO folks are not confusing OO objects with the entity they are
> modeling. One can model an "entity" many ways, with pros and cons to
> various approaches. We can model an entity logically using sets,
> propositions, functions, graphs, OO objects, etc. The question is not
> "which of these is right" but "which of these is most useful for our
> purpose".

Sure, and I code a lot of OO, where the software happily does what its supposed to with no problems. However purposes and requirements change, as do the views of the data that people want. A lot in my albeit limited experience. If I have a system that can cope with that, and still achieve the same results as one can with a biased entity view, then more the better. Perhaps I do not emphasize my pragmatic side enough.

>
> One of the benefits to using something other than RM-as-typically-
> implemented (using the form previously-known-as-1NF, for example) is
> that you do not need to paste (as many) pieces back together in order
> to view or use your model related to a single entity.

Yes, I see the benefit. However I am looking to have my cake and eat it.

> Also, when you
> do paste the pieces back together in a single view, you end up with
> multiple propositions, with information repeated, when using RM-as-
> typically-implemented.

I do not believe RM is the last word in data management. However it offers many important insights which must not be neglected, but built upon imo.

> With OO and other models you might otherwise
> have a single proposition that more closely aligns with a proposition
> one might actually state about the modeled entity

Absolutely. As long as its a proposition (not OO then...) I see nothing wrong with that at all. Cake and eating goodness.

>
> Every model is simply a model (a mathematical metaphor), and not the
> actual object being modeled. So, it will fail to capture everything
> about the thing it is modeling. It must capture that which is
> relevant for purposes of the (user and the) software being written.
> There are issues when modeling at the level of one entity, such as
> asymmetry (and resulting query "bias"). There are also benefits to
> modeling so that you have a good model for "one" (See http://www.tincat-group.com/mewsings/2006/03/data-for-every-1.html). These
> can be discussed as trade-offs, pros and cons, but not in the terms
> you have set up, from my perspective.
>
> --dawn
Received on Mon Feb 05 2007 - 18:58:29 CET