Re: Objects and Relations

From: Cimode <cimode_at_hotmail.com>
Date: 21 Feb 2007 06:02:35 -0800
Message-ID: <1172066553.930724.225120_at_v45g2000cwv.googlegroups.com>


On Feb 21, 1:27 pm, "David BL" <davi..._at_iinet.net.au> wrote:
> On Feb 21, 6:05 pm, "Cimode" <cim..._at_hotmail.com> wrote:
>
>
>
> > On Feb 21, 3:06 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
> > > On Feb 21, 12:03 am, "Walt" <wami..._at_verizon.net> wrote:
>
> > > > In casual conversation, ER modelers will tend to use the simple word
> > > > "entity" in place of either "entity set" or "entity instance", leaving the
> > > > listener to disambiguate by means of the context in whuch the word appears.
>
> > > > By analogy, in casual conversation, object oriented programmers will use the
> > > > simple word "object" in place of either "object class" or "object instance",
> > > > similarly leaving disambiguation up to the listener.
>
> > > > The problem comes when the listener is not familiar with the underlying mode
> > > > of thinking. In that case, the listener will sometimes disambiguate
> > > > incorrectly. That is why introductory tutorials on object oriented
> > > > programming tend to spell out "object class" or "object instance", at least
> > > > until the reader can be presumed to have gotten accustomed to the mode of
> > > > thinking. I'm sure you will have noticed this, if you've gone back and read
> > > > some introductory material after gaining proficiency.
>
> > > > Similarly, introductory material on ER modeling should spell out when we
> > > > are talking about the "set of all vehicles" and when we are talking about "a
> > > > particular vehicle". Some such material does this.
>
> > > > Discourse in this newgroup tends to be a little more formal than casual
> > > > conversation, but far less formal than introductory tutorials.
>
> > > > Hope this helps.
>
> > > I prefer to only use "object" to mean instance. Why would one say
> > > object when one means class? ie given that we have different words
> > > for these different concepts, let's use them!
>
> > > A word like "book" can mean an instance as well as a type, depending
> > > on the context. It could be argued that it really means a type, and
> > > its use for naming an instance is a curious feature of how we
> > > communicate because we don't generally want to go to the trouble to
> > > give things around us explicit names.
>
> > > I agree that "entity" can have both meanings as well. However, I was
> > > taking the statement "entities are illusionary" to mean that all
> > > instances of entities are illusionary, rather than only entity types.
>
> > > It is interesting that in UML we have class diagrams and object
> > > diagrams. An ERD is analogous to a class diagram. That could
> > > explain Jim's tendency to regard "entity" as being a type.
>
> > David. RM uses a more elementary, antecedent and efficient
> > terminology into naming entities, objects, classes, or other OO
> > related concepts. Once you understand that in an RM perspective a
> > class is the representation of some relation and that in RM a relation
> > systematically defines a data type. To understand thoroughly such
> > difference, you need to understand better RM concepts.
>
> > Up to you either to educate yourself
>
> It seems clear that relations give you the effect of a very rich
> taxonomy, if that's what you mean. I agree that the best way by far
> to classify things is through RM.

Besides its *taxonomy* RM primary characteristics is that it is a direct application of set mathematical theory to computing. Its principles are and can be verified as you can verify 1+1. As a consequence, *manipulation* and *operations* over variables are logically supported by mathematical concepts . To understand precisely what I mean by these two terms, you must learn more by reading on RM and RA.

> I guess you could say that RA can be regarded as a means to perform
> (extensional) type analysis. For example you can define a type as the
> set of married humans with green cars, and with minimal effort RA lets
> you calculate the extension of that type. Is that terminology
> acceptable?
Type analysis is one aspect of RM over a million. The terminology is fine but it should not define RM in a restrictive manner.

> I intend to have a read of the material you suggested.
Let me know your conclusions. ;) Received on Wed Feb 21 2007 - 15:02:35 CET

Original text of this message