Entity and Identity
Walter Mitty
in the attempt to overcome the object relational mismatch. Just last week,
I ran across an article that outlines the O-R mapping problem better than I
ever could.
The article is called "The Vietnam of Computer Science", and here's a
pointer:
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
The article devotes rather too much time to exploring the analogy between
the Vietnam war and ORM attempts. And as the article admits, all analogies
eventually fail. Leaving that aside, I think the survey of problems
encountered in crossing the divide is excellent.
I want to draw particular attention to a heading entitled "Entity Identity
Issues". Reading this section gave me a better understanding of the
disconnect between me and Brian Seltzer over matters concerning entity and
identity. My own view of identity is colored by my own experience. And
that experience includes some practical work with relational databases,
preceded by a little formal learning in that area and 20 years of work as a
programmer. Unfortunately, none of that work included object oriented
programming.
Anyway, my view of identity (or of identification, if you prefer) is that an
object's state is all we have to go on as the basis for identification. In
particular, an object's location (as specified by a pointer) or its
trajectory (a history of pointers over time) are unavailable for purposes of
identification. This view of identity fits pretty comfortably into the
relional model, but it runs afoul of object oriented thinking at least two
important ways. Frst, if an object can conceal part of its state
(encapsulation), then it necessarily can conceal some of what needs to be
known to identify it. Second, if two objects are identical in state, then
they are the same object, even if they differ in location (at the same point
in time). I'll call this the "Doppelganger effect".
When I see an SQL table with two different rows in one table that cannot be
distinguished by their contents, my reaction is that the database designer
made a mistake. Failing in that, the database updaters should have been
more careful. Cases where duplication is intentional and carries
significant information strike me as a misuse of SQL, and a misunderstanding
of the relational model.
The above doesn't pretend to explain Brian's view. But I think it sheds a
little light on why I see things the way I do.
Again, I recommend the article cited above.
Tegiri Nenashi
> ... O-R mapping problem ...
A persistent topic indeed (pun intended).
A conventional wisdom is that object encapsulation hides its field
values (state), while relation exposes tuple attributes. Instead,
objects are equipped with some nebulous behavior. I suggest that until
we successfully formalize the latter not much progress is expected.
Each object method is a function, and function is a relation
constrained with functional dependency. So, if we map a "naked" object
into a relation, then the encapsulated counterpart should map into a
set of relations...
Brian
> I've known for quite some time that better minds than mine have gone astray
> in the attempt to overcome the object relational mismatch. Just last week,
> I ran across an article that outlines the O-R mapping problem better than I
> ever could.
>
> The article is called "The Vietnam of Computer Science", and here's a
> pointer:
>
>
> The article devotes rather too much time to exploring the analogy between
> the Vietnam war and ORM attempts. And as the article admits, all analogies
> eventually fail. Leaving that aside, I think the survey of problems
> encountered in crossing the divide is excellent.
>
> I want to draw particular attention to a heading entitled "Entity Identity
> Issues". Reading this section gave me a better understanding of the
> disconnect between me and Brian Seltzer over matters concerning entity and
> identity. My own view of identity is colored by my own experience. And
> that experience includes some practical work with relational databases,
> preceded by a little formal learning in that area and 20 years of work as a
> programmer. Unfortunately, none of that work included object oriented
> programming.
>
> Anyway, my view of identity (or of identification, if you prefer) is that an
> object's state is all we have to go on as the basis for identification. In
> particular, an object's location (as specified by a pointer) or its
> trajectory (a history of pointers over time) are unavailable for purposes of
> identification. This view of identity fits pretty comfortably into the
> relional model, but it runs afoul of object oriented thinking at least two
> important ways. Frst, if an object can conceal part of its state
> (encapsulation), then it necessarily can conceal some of what needs to be
> known to identify it. Second, if two objects are identical in state, then
> they are the same object, even if they differ in location (at the same point
> in time). I'll call this the "Doppelganger effect".
First, it doesn't matter if objects can conceal part of their states
provided that the references to those objects can be used to
distinguish between them, and second, if two objects are identical in
state, then they cannot differ in location, for that would constitute
a difference in state. In the OO world, those references are OIDs,
whose lifetimes coincide with the lifetimes of their respective
objects. Outside the OO world, an identification describes an object,
but just at one time: there can be many descriptions of the same
object at different times, and what describes one object at one time
may describe another object at another time. For objects to be
identical, every description must coincide--that is, at each time in
their lifetimes, what describes one object must also describe the
other.
Cimode
> Again, I recommend the article cited above.
It's always interesting to watch people rediscover some established
truthes using a different pathes...In this case the nebulous path.
The article concludes...
<<
Abandonment. Developers simply give up on objects entirely, and return
to a programming model that doesn't create the object/relational
impedance mismatch. While distasteful, in certain scenarios an object-
oriented approach creates more overhead than it saves, and the ROI
simply isn't there to justify the cost of creating a rich domain
model. ([Fowler] talks about this to some depth.) This eliminates the
problem quite neatly, because if there are no objects, there is no
impedance mismatch.
>>
...which means that one does not always have to try to solve a problem
that would not exist in te first place if objects were no used...Same
reasonning applies to NULL values.
The article also lists as a potential conclusion a
*relationalization* of object oriented...(Reinventing the square wheel
if you will)
For his credit, the writer *did* have the intellectual honnesty to
recognize the fundamental limitation of object mindset. It is just a
shame that he is repeating in an vague way what relational theorists
have been trying to warn the community for decades...
I am seriously beginning to truly believe the myth that OO truly
corrupts cognitive abilities.
paul c
> On Jul 20, 11:51 am, "Walter Mitty" <wami...@verizon.net> wrote:
>> I've known for quite some time that better minds than mine have gone astray
Just because they stray doesn't make them better. Using the word
'mismatch' to compare defined relations and undefined objects is a
misuse of language and basic nonsense. .
David BL
> First, it doesn't matter if objects can conceal part of their states
> provided that the references to those objects can be used to
> distinguish between them, and second, if two objects are identical in
> state, then they cannot differ in location, for that would constitute
> a difference in state.
When you say 'object' do you mean in the OO sense? Usually the OO
community use 'object' to mean an identifiable state machine located
at some address and don't regard the location to be part of its state.
Furthermore usually the identity of an object is determined *only* by
its location and has nothing at all to do with its current state.
David BL
> Anyway, my view of identity (or of identification, if you prefer) is that an
> object's state is all we have to go on as the basis for identification. In
> particular, an object's location (as specified by a pointer) or its
> trajectory (a history of pointers over time) are unavailable for purposes of
> identification. This view of identity fits pretty comfortably into the
> relional model, but it runs afoul of object oriented thinking at least two
> important ways. Frst, if an object can conceal part of its state
> (encapsulation), then it necessarily can conceal some of what needs to be
> known to identify it. Second, if two objects are identical in state, then
> they are the same object, even if they differ in location (at the same point
> in time). I'll call this the "Doppelganger effect".
I find that confusing because it's not clear when you're talking about
your view of identity versus the OO one.
In OO, object identity is usually regarded as determined by object
location and is independent of object state. That of course is very
different to your first sentence above where you say you prefer to use
the object's state as the basis for identification.
However in the context of composing complex state machines out of
simpler ones it is entirely appropriate to identify state machines
independently of their current state. More to the point it wouldn't
make sense to do otherwise. For example two stack objects (i.e.
simple state machines that support push and pop operations) used for
entirely different purposes within a containing state machine may
occasionally have the same state. It wouldn't make sense to say there
is only one stack object whenever that happens. In fact the
containing state machine will normally specify exactly which stack
object a given operation is to be performed on. That wouldn't be
feasible if object identity was determined by state not location.
I find it hard to see how one could define "object" such that object
identity is determined by state not location. You appear to be
thinking about eternal, abstract mathematical values, but it doesn't
make much sense to say that values have state (because that suggests a
value can change) or location (as though a value exists in time and
space).
Walter Mitty
"David BL" <dav...@iinet.net.au> wrote in message
news:f806f72e-b25c-474d...@v23g2000pro.googlegroups.com...
> On Jul 20, 11:51 pm, "Walter Mitty" <wami...@verizon.net> wrote:
>
>> Anyway, my view of identity (or of identification, if you prefer) is that
>> an
>> object's state is all we have to go on as the basis for identification.
>> In
>> particular, an object's location (as specified by a pointer) or its
>> trajectory (a history of pointers over time) are unavailable for purposes
>> of
>> identification. This view of identity fits pretty comfortably into the
>> relional model, but it runs afoul of object oriented thinking at least
>> two
>> important ways. Frst, if an object can conceal part of its state
>> (encapsulation), then it necessarily can conceal some of what needs to
>> be
>> known to identify it. Second, if two objects are identical in state,
>> then
>> they are the same object, even if they differ in location (at the same
>> point
>> in time). I'll call this the "Doppelganger effect".
>
> I find that confusing because it's not clear when you're talking about
> your view of identity versus the OO one.
>
I was talking about my view of identity, and why it doesn't fit well with
the OO view of identity. My understanding of OO is a little hazy.
> In OO, object identity is usually regarded as determined by object
> location and is independent of object state. That of course is very
> different to your first sentence above where you say you prefer to use
> the object's state as the basis for identification.
Thanks for clearing that up. I should clear up that I'm thinking about
storing information about "entities" in an SQL database, and not about
storing that information inside objects in an object world. Some database
designers attempt to copy the OO paradigm and try to assign each object
(what I refer to as an "entity") an OID. The OID is usually the first
column in its table, and is generally the primary key. Foreign key
references to an OID are generally used just as if they were pointers in a
world that's based on pointers.
What I really liked about the article I cited in my OP is that the author
doesn't dismiss either OO thinking or relational thinking as nonsense
perpetrated by inderior minds. The article's understanding of how OO works
is better than mine.
I had understood that an object's identity was independent of its state, but
had failed to appreciate that an object's identity was determined by its
location and nothing else. Your response helps in that regard.
That could make defragmenting an object space into a royal pain. You have
to locate and update all the pointers, or else you invalidate the pointers
you don't update. You can build a garbage collector that doesn't
defragment, but I don't like where that road leads very much.
> However in the context of composing complex state machines out of
> simpler ones it is entirely appropriate to identify state machines
> independently of their current state. More to the point it wouldn't
> make sense to do otherwise. For example two stack objects (i.e.
> simple state machines that support push and pop operations) used for
> entirely different purposes within a containing state machine may
> occasionally have the same state. It wouldn't make sense to say there
> is only one stack object whenever that happens. In fact the
> containing state machine will normally specify exactly which stack
> object a given operation is to be performed on. That wouldn't be
> feasible if object identity was determined by state not location.
>
> I find it hard to see how one could define "object" such that object
> identity is determined by state not location. You appear to be
> thinking about eternal, abstract mathematical values, but it doesn't
> make much sense to say that values have state (because that suggests a
> value can change) or location (as though a value exists in time and
> space).
>
Other people in other discussions have elaborated at great length about the
distinction between a value and a variable.
A location, in the sense that you and I are using that word, is a location
in memory. The contents of memory are variable. At the moment of
retrieval, the contents provide a value. I don';t think it matters whether
the memory space is in RAM or on disk. And the address provided by apointer
can go through one or more mapping operations before finally resolving down
to a physical address.
Brian
I disagree with your use of the terms 'location' and 'identity.' In
the OO world, objects are instances of reference types. The location
of an object can change over its lifetime, but what is used to
reference each object, the object identifier, doesn't. It may be
splitting hairs, but there is a distinct difference between 'identity'
and 'the identity' in that 'identity' is a binary relation between
objects in the universe that denotes /is identical to/, but 'the
identity' of an object is that essential property (unary relation)
which distinguishes it from all other objects (its haecceity) and
which is embodied by an object identifier or by a proper name (in the
logical sense). The identity of an object is determined
(functionally) by its object identifier but can also be determined by
its current state in the same way that a relation schema can have more
than one key. An object representing a particular serialized part can
be identified by its object identifier as well as by the part's serial
number, or by its position on the assembly line relative to all other
similar parts on the line, which could change over time (for example,
the part in front of it may have been scrapped).
David BL
> "David BL" <davi...@iinet.net.au> wrote in message
> > In OO, object identity is usually regarded as determined by object
> > location and is independent of object state. That of course is very
> > different to your first sentence above where you say you prefer to use
> > the object's state as the basis for identification.
>
> Thanks for clearing that up. I should clear up that I'm thinking about
> storing information about "entities" in an SQL database, and not about
> storing that information inside objects in an object world. Some database
> designers attempt to copy the OO paradigm and try to assign each object
> (what I refer to as an "entity") an OID. The OID is usually the first
> column in its table, and is generally the primary key. Foreign key
> references to an OID are generally used just as if they were pointers in a
> world that's based on pointers.
In OO, objects are state machines, not "entities" about which we may
want to record information.
I have no idea why an OO programmer would want to pretend that
employees, companies, departments, teachers or courses are state
machines running on their computer! It's a ridiculous suggestion.
It's also silly for an OO programmer to think that an element of a set
of tuples recorded in a relvar represents a state machine.
> I had understood that an object's identity was independent of its state, but
> had failed to appreciate that an object's identity was determined by its
> location and nothing else. Your response helps in that regard.
>
> That could make defragmenting an object space into a royal pain. You have
> to locate and update all the pointers, or else you invalidate the pointers
> you don't update. You can build a garbage collector that doesn't
> defragment, but I don't like where that road leads very much.
One can for example distinguish between physical memory address and
virtual memory addresses. Also many OO systems allow for objects to
be physically moved by the garbage collector and indeed end up with
different virtual addresses. This is achieved by defining yet another
layer of "virtual" addresses for object references in order to
establish identity. A common approach is for object references to
involve an indirection which could be achieved using a pointer to a
pointer or an index in an array of pointers etc. One could regard the
object reference as a logical identifier for a physical location.
Distinguishing logical addresses from physical addresses is all
relative.
This distinction also exists for OIDs for persistent object stores.
In the literature OIDs are called "logical" if there is an indirection
to the physical location on disk.
> > However in the context of composing complex state machines out of
> > simpler ones it is entirely appropriate to identify state machines
> > independently of their current state. More to the point it wouldn't
> > make sense to do otherwise. For example two stack objects (i.e.
> > simple state machines that support push and pop operations) used for
> > entirely different purposes within a containing state machine may
> > occasionally have the same state. It wouldn't make sense to say there
> > is only one stack object whenever that happens. In fact the
> > containing state machine will normally specify exactly which stack
> > object a given operation is to be performed on. That wouldn't be
> > feasible if object identity was determined by state not location.
>
> > I find it hard to see how one could define "object" such that object
> > identity is determined by state not location. You appear to be
> > thinking about eternal, abstract mathematical values, but it doesn't
> > make much sense to say that values have state (because that suggests a
> > value can change) or location (as though a value exists in time and
> > space).
>
> Other people in other discussions have elaborated at great length about the
> distinction between a value and a variable.
>
> A location, in the sense that you and I are using that word, is a location
> in memory.
Not really. I'm using "location" in a very abstract sense. I allow
any mechanism that allows one to "access" a state machine given some
"address".
> The contents of memory are variable. At the moment of
> retrieval, the contents provide a value.
No! All state machines have state, but not all state machines are
variables that hold an abstract value.
> I don';t think it matters whether
> the memory space is in RAM or on disk. And the address provided by apointer
> can go through one or more mapping operations before finally resolving down
> to a physical address.
Well said.
Walter Mitty
> I have no idea why an OO programmer would want to pretend that
> employees, companies, departments, teachers or courses are state
> machines running on their computer! It's a ridiculous suggestion.
And yet it happens over and over again. We've seen dozens of cases of OO
programmers in here trying to do exactly that.
If you look around the web, the cases multiply into the hundreds. And not
all of those people are morons.
Again, the article on "the Vitenam of Computer Science" does a better job
than I can at motivating why an OO programmer
would want to model his subject matter in terms of objects.
David BL
> On Jul 21, 5:04 am, David BL <davi...@iinet.net.au> wrote:
>
> > On Jul 21, 1:47 am, Brian <br...@selzer-software.com> wrote:
>
> > > First, it doesn't matter if objects can conceal part of their states
> > > provided that the references to those objects can be used to
> > > distinguish between them, and second, if two objects are identical in
> > > state, then they cannot differ in location, for that would constitute
> > > a difference in state.
>
> > When you say 'object' do you mean in the OO sense? Usually the OO
> > community use 'object' to mean an identifiable state machine located
> > at some address and don't regard the location to be part of its state.
> > Furthermore usually the identity of an object is determined *only* by
> > its location and has nothing at all to do with its current state.
>
> I disagree with your use of the terms 'location' and 'identity.' In
> the OO world, objects are instances of reference types. The location
> of an object can change over its lifetime, but what is used to
> reference each object, the object identifier, doesn't.
You're assuming "location" means physical address in memory.
In all OO systems there is a concept of an address space for object
references. Using the street address metaphor we might say that the
objects are located at these addresses. That is what I meant by
"location".
> The identity of an object is determined
> (functionally) by its object identifier but can also be determined by
> its current state in the same way that a relation schema can have more
> than one key.
Agreed, but only assuming "can" is qualified with "sometimes" (not
"always").
In your original statement you implied that location was part of an
object's state. That was the part I disagreed with.
Brian
Yes. Not every relation has more than one key.
>
> In your original statement you implied that location was part of an
> object's state. That was the part I disagreed with.- Hide quoted text -
I stated that a difference in location constitutes a difference in
state. My line of thinking is that what is referenced by each object
identifier is a particular object's state and that each object can
have exactly one state at a time, so when there is more than one
location at a given time, there is more than one state and therefore
there must be more than one object. The eight nodes in your cube of 1-
ohm resistors are distinct even though they can only be distinguished
relative to one another, and in the same way states at different
locations are distinct, even if all of the fields in each state
contain identical values.
>
> - Show quoted text -
David BL
> On Jul 21, 11:15 pm, David BL <davi...@iinet.net.au> wrote:
> > In your original statement you implied that location was part of an
> > object's state. That was the part I disagreed with.- Hide quoted text -
>
> I stated that a difference in location constitutes a difference in
> state.
I don't like that point of view. Typically the possible states of a
state machine can be identified independently of the identity of the
state machine. It then follows that it can be possible to say that
two distinct state machine instances (i.e. at different "locations")
happen to be in the same state at a given time.
> My line of thinking is that what is referenced by each object
> identifier is a particular object's state and that each object can
> have exactly one state at a time, so when there is more than one
> location at a given time, there is more than one state and therefore
> there must be more than one object.
You seem to be saying that a state machine *is* its (current) state.
I would rather say that a state machine *has* a (current) state.
If you say that a state machine is its state, then when it's state
changes it's not the same state machine. That doesn't make sense
(because state machines can normally change states without losing
their identity).
I think you're mucking up the simple (definitional) distinction
between the "location" and "state" of an instance of a state machine
that exists in some address space.
> The eight nodes in your cube of 1-
> ohm resistors are distinct even though they can only be distinguished
> relative to one another, and in the same way states at different
> locations are distinct, even if all of the fields in each state
> contain identical values.
That discussion will probably lead us into confusion between state
machine and value!
Nilone
> "David BL" <davi...@iinet.net.au> wrote in message
OO programmers do it because that is what they were trained to do.
Take a look at http://java.sun.com/docs/books/tutorial/java/concepts/object.html.
It sounds great, like playing with Lego and being able to design your
own pieces. All the big language vendors are offering it, so they
think it's a proven technology.
OO is broken, and most programmers don't see it. Encapsulation is
fine, but inheritance breaks it. Inheritance could work, but
overriding can break any promises made by the original code. Single
inheritance (due to the diamond problem created by overriding) forces
ideas into unnatural and limited hierarchies and restrict modularity.
Mutable objects and overriding destroy any hope of subtyping and
polymorphism. Design patterns and frameworks add so much code that
any possible benefit is negated a thousand times over.
Other paradigms seem difficult and artificial, since they force one to
do things in a certain, logical way. OO is an easy, slippery slide
into the bowels of hell.
Walter Mitty
"Nilone" <rea...@gmail.com> wrote in message
news:968d267b-cb1f-4845...@h21g2000yqa.googlegroups.com...
>On Jul 22, 5:15 am, "Walter Mitty" <wami...@verizon.net> wrote:
>OO programmers do it because that is what they were trained to do.
>Take a look at
>http://java.sun.com/docs/books/tutorial/java/concepts/object.html.
>It sounds great, like playing with Lego and being able to design your
>own pieces. All the big language vendors are offering it, so they
>think it's a proven technology.
>OO is broken, and most programmers don't see it.
That might explain why the thundering herd follows OO, but it doesn't
explain why leaders in the field recommend it.
I can't comment on whether your claim is valid or not, because I've never
attempted an industrial strength project using OO design.
But I can say that it would surprise me if the industry were captrivated by
a broken paradigm for as long as OO has been dominant in the world of
programming.
I'll mention in passing that there was a constant visitor who spent about
three years in this forum claiming that the RM was counterproductive, and
that products like Oracle, DB2, and SQL server had delayed the forward
progress in the state of the art. That person's arguments were not
persuasive to the vast majority of the regulars here. The arguments were
largely based on anecdotal evidence and non sequiturs. My own personal
experience was enough to contradict the anecdotal evidence in my mind. The
non sequiturs fell of their own weight.
For the theoreticians in the newsgroup, the theoretical underpinnings of the
RM were sufficient to contradict the claim that RM was either broken or
ocunterproductive.
But the larger counter argument was to ask how the industry could have been
captivated by a giant blunder over a period of decades.
I would ask the same question about OO, even though I am in no way an OO
fan.
Nilone
> I've known for quite some time that better minds than mine have gone astray
> in the attempt to overcome the object relational mismatch. Just last week,
> I ran across an article that outlines the O-R mapping problem better than I
> ever could.
>
> The article is called "The Vietnam of Computer Science", and here's a
> pointer:
>
The article states: 'The opposite approach--a "relational-only"
approach--is almost nonsensical to consider, given the technology of
the day at the time this was written'
It sounds as if it just might be doable. Not like a D language, but
like a DBMS with support for executing certain forms of data (since
code is just another type of data, lisp and prolog proved that). All
functions are relations, right? So can a functional programming
paradigm be embedded in the relational model? Is there a relational
model of computation? Just wondering...
Cimode
> It sounds as if it just might be doable. Not like a D language, but
> like a DBMS with support for executing certain forms of data (since
> code is just another type of data, lisp and prolog proved that). All
> functions are relations, right? So can a functional programming
> paradigm be embedded in the relational model? Is there a relational
> model of computation? Just wondering...
A good start for you...
Cimode
> Other paradigms seem difficult and artificial, since they force one to
> do things in a certain, logical way. OO is an easy, slippery slide
> into the bowels of hell.
Object-oriented programming is an exceptionally bad idea which could
only have originated in California.
Edsger Dijkstra
Nilone
Your counter-argument boils down to an appeal to popular opinion,
which is not a valid argument. I'll answer it anyway. I should note
that when I rail against OO, I mean class-based OO with inheritance
and overriding.
Programmers and businesses can't simply and easily decide what
paradigm to use based on its merits. They buy into a language based
on a number of factors, and the merits of a paradigm is only a small
part of it. Other factors include popular opinion, opinion of
business partners, clients' opinions, big vendor support, commercial
support, compatibility with associated platforms and tools, and ease
of learning. OO is strong in all of these. It is only weak in its
logic, which is usually not considered at all.
Since programmers and businesses have a vested interest in supplying
what other programmers and businesses want, any paradigm will be self-
propagating and self-sustaining. OO literature and tools abound,
which makes it near impossible to not use it. Many businesses benefit
from applying OO analysis and design, since any analysis and design is
better than none. OO problems are only discovered after a lot of time
and effort have been invested, at which point it simply isn't cost-
effective to back out.
The problems I mentioned are not anecdotal, they're documented. For
reference, look at the diamond problem, circle-ellipse problem,
subtyping vs subclassing, and the Liskov substitution principle.
Take a look at entity systems in game development, which provides
insight into what OO could have been. It just so happens that these
entity systems are very compatible with the relational model.
Take a look at the Theory of Classification (http://www.dcs.shef.ac.uk/
~ajhs/classify/), which attempts to place OO on a solid theoretical
foundation by describing classes as function-bounded type generators,
i.e. second-order logic constructs.
Nilone
That page is empty. I'm well familiar with the site, though. Did you
have a specific book in mind?
Cimode
> > Read...
>
> > A good start for you...
>
> >http://www.dbdebunk.com/books.html
>
> That page is empty. I'm well familiar with the site, though. Did you
> have a specific book in mind?
would recommend
Cimode
Nilone
It needs to be said, again and again and again, until OO programmers
get it. Unfortunately, I'm saying it in the one group that knows it.
Perhaps I should have cross-posted to comp.object ;)
Cimode
Given that the quote provided comes from a far past, computing wise, I
seriously doubt that would have any effect today...
paul c
One contingency that military planners or their political masters have
often failed to allow for is the enemy that refuses to fight according
to the official battle plan. Sometimes this is called 'exit strategy'.
In the metadata thread I was surprised you didn't mention one of Codd's
basic points - metadata is amenable to the same operators and logical
structures as data. This feature could be viewed as an exit tactic. In
RT, there are others, perhaps the most basic is the Information
Principle. If there really is an "OO-mismatch" it is that data is
permanently cast according to a single perspective for which there may
well be no exit strategy.
Nilone
> > > Read...
>
> > > A good start for you...
>
> > >http://www.dbdebunk.com/books.html
>
> > That page is empty. I'm well familiar with the site, though. Did you
> > have a specific book in mind?
>
> It really depends where you start from...Given the points you raised I
> would recommend
>
On Jul 22, 4:56 pm, Cimode <cim...@hotmail.com> wrote:
> I'd also read...
>
> http://www.amazon.com/dp/0201485559?tag=databasede095-20&camp=14573&c...
Aye, it's a crying shame I don't have those yet. They're at the top
of my list now, thanks.
Tegiri Nenashi
IMO function viewed as a relation offers too little insight to be
practically useful (yet). Function composition is relational join
(followed by projection of intermediate attributes) -- that is about
it. What is recursion from relational perspective?
I would suggest that the theory of binary relations (aka Relation
Algebra) is more useful in computational world. Function composition
is the exact relational composition (join). Roland Backhouse pioneered
this direction, and J.N.Oliveira leaning it more towards databases...
Walter Mitty
"paul c" <toledob...@oohay.ac> wrote in message
news:NGG9m.37712$PH1.5386@edtnps82...
> One contingency that military planners or their political masters have
> often failed to allow for is the enemy that refuses to fight according to
> the official battle plan. Sometimes this is called 'exit strategy'. In
> the metadata thread I was surprised you didn't mention one of Codd's basic
> points - metadata is amenable to the same operators and logical structures
> as data. This feature could be viewed as an exit tactic. In RT, there
> are others, perhaps the most basic is the Information Principle. If there
> really is an "OO-mismatch" it is that data is permanently cast according
> to a single perspective for which there may well be no exit strategy.
I don't get the connection between the enemy's refusal to fight according to
the battle plan and what is called an "exit strategy".
As far as the single perspective on data goes, one of the topics in the
essay is called "The Dual-Schema problem." It seems to me that this
problem, as outlined in the essay, is central to the ongoing battles between
OO enthusiasts and RM enthusiasts. My own pattern, during the time I was
working with databases, was to adopt the RM (or more precisely the SQL
approximation to the RM) for data definition and use procedural code for
data processing. The problems I was tackling were relatively simple
processing rules applied to richly structured data. A lot of commercial
data processing is like that.
The fact that the processing was fairly simple meant that I lost fairly
little by coding programs in terms of procedures rather than objects. And,
with a few proprietary extensions, SQL works pretty well as a procedural
language. So I pretty much worked with one schema and one language. I
didn't know it at the time, but I had it easy. It's possible that OO
programmers have it much tougher because an object world has a schema, sort
of. An OO schema is much more implicit than a database schema. It's the
explicitness of the database schema that makes databases so powerful. At
the same time, the diffculty of getting a schema right the first time, and
the high cost of getting a schema wrong is what makes database work seem so
difficult to otherwise competent professionals.
What I'd like to see is a way that an OO programming language could work
with data defined according to a relational schema. The big problem seems
to be that OO doesn't have a good way of describing sets of objects in such
a way that an operation on the set can be resolved down to a series of
operations on the elements. That's the big thing that I think the query
executor does for me in an SQL environment. Presumably, it would do as much
or more for me in a D environment.
paul c
...
>
> I don't get the connection between the enemy's refusal to fight according to
> the battle plan and what is called an "exit strategy".
There are lots of obvious comparisons. A most basic one is (the naive,
unthinking, absurd assumption) that a procedural approach, eg.,
programming perspective, can somehow co-exist with a declarative one.
As far as preserving the essence of data is concerned, the procedural
(so-called OORDMS or suchlike) people, by their beginning assumptions,
set themselves up for disaster before they even start. Subsequently
they conclude other nonsense, such as the notion that there is some kind
of post-hoc reconciliation possible.
Cimode
> As far as preserving the essence of data is concerned, the procedural
> (so-called OORDMS or suchlike) people, by their beginning assumptions,
> set themselves up for disaster before they even start. Subsequently
> they conclude other nonsense, such as the notion that there is some kind
> of post-hoc reconciliation possible.
Cimode
> they conclude other nonsense, such as the notion that there is some kind
> of post-hoc reconciliation possible.
be imagined, OO proponents would certainly not be able to find it.
Nilone
I think you're confusing procedural with OO, which is often built on
top of procedural languages, although OO have been tacked onto
functional languages too. OO always needs another paradigm to ride,
since it isn't a model of computation but a broken type system mixed
with a module system. Procedural can exist quite happily with
declarative - take a look at the procedural interpretation of horn
clauses, and continuation passing style programming.
Nilone
Yes, that's what I was looking for. Function composition is join, and
then function application would be selection, right? The domain of
the function is the propositional condition that restricts the
selection, while the codomain would be the projection of the resulting
set of tuples. Recursive queries would substitute the result set into
the the selection condition (of course they would have to be the same
type). Recursively defined relations would produce infinite sets.
Any more references or information in this line?
I looked at some pages on relation algebra, but it's still beyond me,
I'll keep working at it, thanks for the info.
paul c
...
> with a module system. Procedural can exist quite happily with
> declarative - take a look at the procedural interpretation of horn
> clauses, and continuation passing style programming.
The popular OO programming techniques/languages commonly depend on
assignment, no matter how much they pretend otherwise. For the ones
that don't, there might be cases where I'd grant your point. A
procedural interpretation on top of a declarative system is a different
dimension from one that is logically equivalennt, a bizarre hybrid, like
mules who can't reproduce and comparable to nothing and everything at
the same time. The clause perspectives you're talking about could be
interchangeable in some settings and one might not need to depend on
both at the same time in order to understand the intention or get
results. Whereas the OO-relational silly conciliators basically pretend
that a relational scheme is nothing more than a file system. This is of
the same uselessness as EAV because it is fatuous to build something you
already have. It amounts to accepting unneeded complexity for the sake
of 'jobs for the boys'. Good cooks know to never combine more than
three basic flavours, in programming it is ideal to keep that down to
one flavour, same reason as a man with two watches never knows what time
it is (and this ignores the general incompetence of most programmers,
which is another story entirely).. These comparisons may seem like
obfuscation to some literalists but they are actually just as relevent
as those horn clause and continuation comparisons. I was surprised that
Djikstra didn't mention a few other states besides California!
paul c
...
> Yes, that's what I was looking for. Function composition is join, and
> then function application would be selection, right? The domain of
> the function is the propositional condition that restricts the
> selection, while the codomain would be the projection of the resulting
> set of tuples. Recursive queries would substitute the result set into
> the the selection condition (of course they would have to be the same
> type). Recursively defined relations would produce infinite sets.
> Any more references or information in this line?
>
> I looked at some pages on relation algebra, but it's still beyond me,
> I'll keep working at it, thanks for the info.
See TTM Appendix A (pdf is online at ttm site) for concise explanations
that reduce composition and selection to combinations of join and
project, from a relational algebra viewpoint, it includes very tidy
formal definitions.
Cimode
> I was surprised that
> Djikstra didn't mention a few other states besides California!
the plague *yet*...
Nilone
Just read it, thanks. I'll have to get the book soon, I keep getting
into things which have already been worked out.
BTW, I also came across the following article, which looks
interesting:
RELATIONAL MODEL FOR PROGRAM SEMANTICS
http://www.ohiolink.edu/etd/send-pdf.cgi/Punnam%20Pradeep%20Kumar.pdf?acc_num=kent1226606883
David BL
> Your counter-argument boils down to an appeal to popular opinion,
> which is not a valid argument. I'll answer it anyway. I should note
> that when I rail against OO, I mean class-based OO with inheritance
> and overriding.
That's an interesting point because in my experience the best OO
programmers only tend to subclass pure abstract base classes (at least
where virtual functions are involved). In other words, subclassing
has more to do with subtyping than inheritance (of implementation).
On another note, mixins (i.e. classes templatised on base classes)
appear to avoid many of the pitfalls of conventional inheritance. For
example, they eliminate the need for multiple inheritance.
Nevertheless again, the best OO programmers prefer simple composition
to achieve code reuse.
I think there is a huge variation in the practise of OO. It is
obviously a dangerous tool to wield. Despite this I believe there are
many valid uses, even if they are hard to find amongst all the
horrible implementations out there.
A good application of OO: A pure abstraction for a flushable output
stream:
// C++
struct OutputStream
{
virtual void write(void* buf, int cnt) = 0;
virtual void flush() = 0;
};
This allows for connecting one of many different 'suppliers' - i.e.
implementers of the interface to one of many different 'clients' that
can use the interface. This connection can be achieved at run time
even though client and supplier are compiled and linked in isolation.
Note that buffering the entire output may not be a viable alternative
which seems to imply that the client must make calls on the supplier.
That to me is what best characterises OO. It's not clear to me what
alternatives exist. For example, I'm wondering whether there's an
approach that achieves a similar degree of decoupling in a pure
functional language. It seems unlikely to me because an implementer
of an output stream must surely be regarded as a state machine. For
example, consider an open socket connection. I fail to see how one
can think of it as an abstract value, nor indeed an assignable
variable that holds an abstract value. This is indeed where I dispute
Paul's comment elsewhere:
"The popular OO programming techniques/languages
commonly depend on assignment, no matter how much
they pretend otherwise."
I understand and respect what Paul meant by that comment. However I
think he has missed the point that OO systems are composed from state
machines where assignment often becomes an implementation detail, and
indeed assignment of state is unable to model the inner workings of
objects that perform I/O with devices like hardware clocks, disk
drives, printers, and network cards. In addition, a computing model
based solely on assignable variables is inappropriate to model
threads, thread pools, thread schedulers, mutexes, semaphores etc,
because these all interact with the CPU in special ways (e.g. in order
to initiate a context switch or to execute a memory fence
instruction).
I conclude that OO can be useful for systems programming. But is it
any good for "application programming", and can the distinction be
formalised?
Nilone
The problem is that "appropriate use" always requires limiting which
features of OO you apply. Implementing interfaces are fine, but that
should be extracted into a separate mechanism so that it can be used
safely. There are other appropriate uses that could, and should, be
formalised. Each aspect of OO was meant with good intentions, and
works individually, but not together.
It is easy to contrive an interface to a flushable output stream by
passing around pointers to shared memory containing executable code
and space for buffers and whatever else you want to do. It would be
safe when used appropriately. BTW, GOTO is useful too, when used
appropriately.
The point is, if we're going to have abstraction mechanisms, it needs
to be the right mechanism. The relational model is an example of
such. It works for any composition of its features. The user may not
understand the model, and thus the consequences of how they use it,
but that is not the fault of the model. The information is available,
and the consequences of applying the model is clearly defined.
With OO, only a very specific subset of the possible compositions of
its features are valid and useful. Using some features together
breaks the promises made by the abstraction mechanism, i.e. it
violates its own reason for existence when used incorrectly. And
doing is so is very, very easy.
I believe programmers will be best served by completely discarding OO
as currently understood.
Brian
> On Jul 22, 12:57 pm, Brian <br...@selzer-software.com> wrote:
>
> > On Jul 21, 11:15 pm, David BL <davi...@iinet.net.au> wrote:
> > > In your original statement you implied that location was part of an
> > > object's state. That was the part I disagreed with.- Hide quoted text -
>
> > I stated that a difference in location constitutes a difference in
> > state.
>
> I don't like that point of view. Typically the possible states of a
> state machine can be identified independently of the identity of the
> state machine. It then follows that it can be possible to say that
> two distinct state machine instances (i.e. at different "locations")
> happen to be in the same state at a given time.
It may again be splitting hairs, but I would argue that it is the
possible sets of field values rather than the possible states that can
be determined independently, from the standpoint that a state is a set
of field values /for/ a particular state machine and thus cannot be
divorced from it. For there to be a state requires first that there
be a state machine! It then follows that it can be possible for two
distinct state machines to have equivalent, but not identical, states
at a given time.
>
> > My line of thinking is that what is referenced by each object
> > identifier is a particular object's state and that each object can
> > have exactly one state at a time, so when there is more than one
> > location at a given time, there is more than one state and therefore
> > there must be more than one object.
>
> You seem to be saying that a state machine *is* its (current) state.
> I would rather say that a state machine *has* a (current) state.
How did you come to that conclusion? If you look closely, what I
actually said was "each object can *have* exactly one state at a
time."
<snip>
> > The eight nodes in your cube of 1-
> > ohm resistors are distinct even though they can only be distinguished
> > relative to one another, and in the same way states at different
> > locations are distinct, even if all of the fields in each state
> > contain identical values.
>
> That discussion will probably lead us into confusion between state
> machine and value!
I don't think it will. There are state machines and there are values,
and there are values for state machines. So you can have a state
machine, o, and a value, v, and a value for a state machine (o,v).
Walter Mitty
> Each aspect of OO was meant with good intentions, and
> works individually, but not together.
This is the great pitfall of adhocracy.
>The point is, if we're going to have abstraction mechanisms, it needs
>to be the right mechanism. The relational model is an example of
>such. It works for any composition of its features. The user may not
>understand the model, and thus the consequences of how they use it,
>but that is not the fault of the model. The information is available,
>and the consequences of applying the model is clearly defined.
>With OO, only a very specific subset of the possible compositions of
>its features are valid and useful. Using some features together
>breaks the promises made by the abstraction mechanism, i.e. it
>violates its own reason for existence when used incorrectly. And
>doing is so is very, very easy.
Both RM and OO can be easily misused, as evidenced by the last thirty
years. Whether one case is the fault of the learners and the other is the
fault of the model itself is a case that's yet to be made, IMO. You make a
good case that RM is internally coherent and that OO may lack that internal
coherence. That does make RM easier to learn correctly for a certain subset
of those who set out to learn it. But only for that certain subset.
>I believe programmers will be best served by completely discarding OO
>as currently understood.
Is OO as currently understood different from what Alan Kay had in mind back
at Xerox Parc? In what ways? What other luminaries aside from Alan Kay can
speak for OO as a whole? What would programmers be better served by than
OO?
At the risk of answering my own question, I'm going to say what I think the
great divide between good programmers and good database experts was some 25
years ago, when I learned about databases. The great divide was between
"process centered thinking" and "data centered thinking". This was more a
matter of modes of thought than of languages and tools. But the two kinds
of thinkers will gravitate towards different kinds of languages and tools.
It's not clear to me, but I rather think that OO is a tool for process
centered thinkers.
Nilone
> "Nilone" <rea...@gmail.com> wrote in message
>
> news:a638cd4a-0dde-40e1...@b14g2000yqd.googlegroups.com...
>
> > Each aspect of OO was meant with good intentions, and
> > works individually, but not together.
>
> This is the great pitfall of adhocracy.
Exactly.
>
> >The point is, if we're going to have abstraction mechanisms, it needs
> >to be the right mechanism. The relational model is an example of
> >such. It works for any composition of its features. The user may not
> >understand the model, and thus the consequences of how they use it,
> >but that is not the fault of the model. The information is available,
> >and the consequences of applying the model is clearly defined.
> >With OO, only a very specific subset of the possible compositions of
> >its features are valid and useful. Using some features together
> >breaks the promises made by the abstraction mechanism, i.e. it
> >violates its own reason for existence when used incorrectly. And
> >doing is so is very, very easy.
>
> Both RM and OO can be easily misused, as evidenced by the last thirty
> years. Whether one case is the fault of the learners and the other is the
> fault of the model itself is a case that's yet to be made, IMO.
No, I'm making it now.
> You make a
> good case that RM is internally coherent and that OO may lack that internal
> coherence. That does make RM easier to learn correctly for a certain subset
> of those who set out to learn it. But only for that certain subset.
Ease of learning never trumps correctness. It's much easier to
remember that everything adds up to 0 than it is to learn to do
arithmetic.
>
> >I believe programmers will be best served by completely discarding OO
> >as currently understood.
>
> Is OO as currently understood different from what Alan Kay had in mind back
> at Xerox Parc? In what ways? What other luminaries aside from Alan Kay can
> speak for OO as a whole? What would programmers be better served by than
> OO?
Yes, it's very different. A quote from
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en:
"OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other systems
in which this is possible, but I'm not aware of them."
Pretty much any of the existing alternatives to OOP would be better.
Functional seems to be the favorite of language designers now.
Personally, I'd like to see relational go all the way.
>
> At the risk of answering my own question, I'm going to say what I think the
> great divide between good programmers and good database experts was some 25
> years ago, when I learned about databases. The great divide was between
> "process centered thinking" and "data centered thinking". This was more a
> matter of modes of thought than of languages and tools. But the two kinds
> of thinkers will gravitate towards different kinds of languages and tools.
> It's not clear to me, but I rather think that OO is a tool for process
> centered thinkers.
There are better tools. Ones that aren't broken.
David BL
> The problem is that "appropriate use" always requires limiting which
> features of OO you apply. Implementing interfaces are fine, but that
> should be extracted into a separate mechanism so that it can be used
> safely.
I'm associating OO with *any* approach (however carefully formalised)
that involves identifiable state machines that tend to be accessed
through function/procedure calls in a way that supports dynamic
polymorphism. I don't consider "OO" to be defined by the current
suite of mainstream languages out there.
I don't understand in what way implementing and using interfaces can
be made "safe" by extracting into a "separate mechanism" that
presumably is no longer OO. If that's what you mean you're going to
need to justify such a bold statement!
> There are other appropriate uses that could, and should, be
> formalised. Each aspect of OO was meant with good intentions, and
> works individually, but not together.
Can you give an example? I don't mean an example of a poor
application of OO (they're everywhere), but rather an example of two
aspects of OO that don't work together in general and why you think
that is bad.
> It is easy to contrive an interface to a flushable output stream by
> passing around pointers to shared memory containing executable code
> and space for buffers and whatever else you want to do. It would be
> safe when used appropriately. BTW, GOTO is useful too, when used
> appropriately.
I fail to see the point you're making here. My point was that OO was
a natural fit for the concept of a state machine representing an
output stream, and FP, LP, RM+RA are not. The implication is that OO
is sometimes useful. You appear to be arguing that OO is never
useful. Is that right?
An OO style language makes it relatively easy to directly express the
concepts of 1) defining the state machine interface, 2) implementing
the interface and 3) using the interface.
The following might be a better example:
struct Task
{
virtual void Execute() = 0;
virtual void Abort() = 0;
};
struct ThreadPool
{
virtual void Close() = 0;
virtual void PostTask(Task*) = 0;
};
ThreadPool* CreateThreadPool();
Note that the execute and abort methods on an abstract task have no
"data exchange" whatsoever (they takes no arguments and have no return
value). For that reason an abstract task is hardly going to map into
a "data centric" language (such as a pure FP language).
I think thread pools are a useful concept and OO is a very good fit.
> The point is, if we're going to have abstraction mechanisms, it needs
> to be the right mechanism. The relational model is an example of
> such. It works for any composition of its features. The user may not
> understand the model, and thus the consequences of how they use it,
> but that is not the fault of the model. The information is available,
> and the consequences of applying the model is clearly defined.
If you're saying that the RM is a well defined mathematical formalism
whereas OO is not then I completely agree.
It's not clear what you mean when you imply that the consequences of
using OO aren't clearly defined. For example, with effort one can
write OO programs in a particular language and construct proofs of
correctness against requirements. Nondeterminism isn't the problem!
Difficulty of writing correct programs is the killer.
I hope you're not suggesting that the RM is always "the right
mechanism". Even in the arena of data representation and manipulation
it is poorly suited to algebraic data types:
http://en.wikipedia.org/wiki/Algebraic_data_type
> With OO, only a very specific subset of the possible compositions of
> its features are valid and useful. Using some features together
> breaks the promises made by the abstraction mechanism, i.e. it
> violates its own reason for existence when used incorrectly. And
> doing is so is very, very easy.
>
> I believe programmers will be best served by completely discarding OO
> as currently understood.
I don't find your argument persuasive. I would simply say that OO is
(only) well suited to a narrow problem domain. Since programming
general purpose state machines is very difficult it stands to reason
that OO should only be used by competent programmers in those
instances where it is appropriate.
David BL
> On Jul 22, 3:21 am, David BL <davi...@iinet.net.au> wrote:
>
> > On Jul 22, 12:57 pm, Brian <br...@selzer-software.com> wrote:
>
> > > On Jul 21, 11:15 pm, David BL <davi...@iinet.net.au> wrote:
> > > > In your original statement you implied that location was part of an
> > > > object's state. That was the part I disagreed with.- Hide quoted text -
>
> > > I stated that a difference in location constitutes a difference in
> > > state.
>
> > I don't like that point of view. Typically the possible states of a
> > state machine can be identified independently of the identity of the
> > state machine. It then follows that it can be possible to say that
> > two distinct state machine instances (i.e. at different "locations")
> > happen to be in the same state at a given time.
>
> It may again be splitting hairs, but I would argue that it is the
> possible sets of field values rather than the possible states that can
> be determined independently, from the standpoint that a state is a set
> of field values /for/ a particular state machine and thus cannot be
> divorced from it.
Some definitions of an abstract state machine don't have any concept
of "field values". E.g. sometimes a state machine is defined by an
abstract set of states, a transition function etc.
> For there to be a state requires first that there
> be a state machine!
That makes it difficult to talk about a state machine 'class' (using
OO speak). For example I may want to use {0,1,2,3} to represent a set
of possible states for a class of state machine, and write proofs
about behaviour of all run time instances of that class (before I've
even run the program).
> It then follows that it can be possible for two
> distinct state machines to have equivalent, but not identical, states
> at a given time.
I agree it is possible to require that every run time instance of a
state machine has its own "private" set of states. But what is the
advantage in making that restriction? I cannot see any basis for it,
and a lot of good reasons not to.
> > > My line of thinking is that what is referenced by each object
> > > identifier is a particular object's state and that each object can
> > > have exactly one state at a time, so when there is more than one
> > > location at a given time, there is more than one state and therefore
> > > there must be more than one object.
>
> > You seem to be saying that a state machine *is* its (current) state.
> > I would rather say that a state machine *has* a (current) state.
>
> How did you come to that conclusion? If you look closely, what I
> actually said was "each object can *have* exactly one state at a
> time."
You said:
"what is referenced by each object identifier is a
particular object's state."
I would instead say: what is referenced by each object identifier is
a particular object.
I reconciled the two by assuming you believed an object is nothing
more than its state (and I agree with you that this pov would seem to
imply that distinct objects necessarily have distinct sets of states).
> > > The eight nodes in your cube of 1-
> > > ohm resistors are distinct even though they can only be distinguished
> > > relative to one another, and in the same way states at different
> > > locations are distinct, even if all of the fields in each state
> > > contain identical values.
>
> > That discussion will probably lead us into confusion between state
> > machine and value!
>
> I don't think it will. There are state machines and there are values,
> and there are values for state machines. So you can have a state
> machine, o, and a value, v, and a value for a state machine (o,v).
In the sense that source code is data, I regard a state machine class
as an abstract value whereas a state machine instance running on a
physical computer exists in time and space. The former is a pure
mathematical abstraction divorced from the physical. The latter is an
abstraction over the physical. This is commonly called the compile
time versus run time distinction.
It potentially gets confusing given the idea of composing state
machines, which can be described at compile time and also somewhat
independently at run time. For example, one can instantiate a state
machine class multiple times within a containing state machine class.
However, in that case the instantiations are part of a containing
abstract value. This is similar to instantiating an abstract sub-
circuit value within a containing abstract circuit value, and not to
be confused with a physical instantiation (or "appearance") of a
circuit in time and space.
Nilone
> On Jul 23, 6:43 pm, Nilone <rea...@gmail.com> wrote:
>
> > The problem is that "appropriate use" always requires limiting which
> > features of OO you apply. Implementing interfaces are fine, but that
> > should be extracted into a separate mechanism so that it can be used
> > safely.
>
> I'm associating OO with *any* approach (however carefully formalised)
> that involves identifiable state machines that tend to be accessed
> through function/procedure calls in a way that supports dynamic
> polymorphism. I don't consider "OO" to be defined by the current
> suite of mainstream languages out there.
I'm opposing OO as implemented in the current suite of mainstream
languages - more specifically, I'm opposing the class systems of
mainstream languages. I have no problem with state machines.
>
> I don't understand in what way implementing and using interfaces can
> be made "safe" by extracting into a "separate mechanism" that
> presumably is no longer OO. If that's what you mean you're going to
> need to justify such a bold statement!
>
> > There are other appropriate uses that could, and should, be
> > formalised. Each aspect of OO was meant with good intentions, and
> > works individually, but not together.
>
> Can you give an example? I don't mean an example of a poor
> application of OO (they're everywhere), but rather an example of two
> aspects of OO that don't work together in general and why you think
> that is bad.
The point is that OO class systems are broken in the sense that they
allow known poor applications, due to their conflation of the
concepts. So far, I can see three concepts combined into the idea of
classes: interfaces, types and state machines. OO classes allow one
to create things which are none of the above, in which case any code
which operates on objects as one or the other is likely to fail
eventually.
>
> > It is easy to contrive an interface to a flushable output stream by
> > passing around pointers to shared memory containing executable code
> > and space for buffers and whatever else you want to do. It would be
> > safe when used appropriately. BTW, GOTO is useful too, when used
> > appropriately.
>
> I fail to see the point you're making here. My point was that OO was
> a natural fit for the concept of a state machine representing an
> output stream, and FP, LP, RM+RA are not. The implication is that OO
> is sometimes useful. You appear to be arguing that OO is never
> useful. Is that right?
No, I'm saying the current implementations of OO classes cause too
many issues to make them worth the effort. Nearly all available OO
documentation leads one away from a clear understanding of the issues.
OO classes as a type system doesn't prevent subtypes from breaking
existing working code, and can't be relied on for the purpose for
which they are intended.
>
> I hope you're not suggesting that the RM is always "the right
> mechanism". Even in the arena of data representation and manipulation
> it is poorly suited to algebraic data types:
>
> http://en.wikipedia.org/wiki/Algebraic_data_type
The RM doesn't strive to be everything. It is an exceptionally useful
tool with wide application in programming. Current OO implementations
strive to be everything to everyone.
>
> > With OO, only a very specific subset of the possible compositions of
> > its features are valid and useful. Using some features together
> > breaks the promises made by the abstraction mechanism, i.e. it
> > violates its own reason for existence when used incorrectly. And
> > doing is so is very, very easy.
>
> > I believe programmers will be best served by completely discarding OO
> > as currently understood.
>
> I don't find your argument persuasive. I would simply say that OO is
> (only) well suited to a narrow problem domain. Since programming
> general purpose state machines is very difficult it stands to reason
> that OO should only be used by competent programmers in those
> instances where it is appropriate.
State machines are great. I'd be happy enough if OO, as commonly
understood and implemented in mainstream languages, were limited to
state machines.
Brian
> On Jul 23, 6:50 pm, Brian <br...@selzer-software.com> wrote:
<snip>
> > It may again be splitting hairs, but I would argue that it is the
> > possible sets of field values rather than the possible states that can
> > be determined independently, from the standpoint that a state is a set
> > of field values /for/ a particular state machine and thus cannot be
> > divorced from it.
>
> Some definitions of an abstract state machine don't have any concept
> of "field values". E.g. sometimes a state machine is defined by an
> abstract set of states, a transition function etc.
So? Isn't a set of values still a value?
> > For there to be a state requires first that there
> > be a state machine!
>
> That makes it difficult to talk about a state machine 'class' (using
> OO speak). For example I may want to use {0,1,2,3} to represent a set
> of possible states for a class of state machine, and write proofs
> about behaviour of all run time instances of that class (before I've
> even run the program).
I don't see how treating states as mappings between the domain of
objects of a particular type and the domain of possible values for
those objects would make it any more difficult to talk about a state
machine 'class.'
The context of the entire sentence is "at a given time," and since an
object can only have exactly one state "at a given time," it stands to
reason that the object identifier [indirectly] references a particular
object's state "at a given time."
>
> > > > The eight nodes in your cube of 1-
> > > > ohm resistors are distinct even though they can only be distinguished
> > > > relative to one another, and in the same way states at different
> > > > locations are distinct, even if all of the fields in each state
> > > > contain identical values.
>
> > > That discussion will probably lead us into confusion between state
> > > machine and value!
>
> > I don't think it will. There are state machines and there are values,
> > and there are values for state machines. So you can have a state
> > machine, o, and a value, v, and a value for a state machine (o,v).
>
> In the sense that source code is data, I regard a state machine class
> as an abstract value whereas a state machine instance running on a
> physical computer exists in time and space. The former is a pure
> mathematical abstraction divorced from the physical. The latter is an
> abstraction over the physical. This is commonly called the compile
> time versus run time distinction.
>
> It potentially gets confusing given the idea of composing state
> machines, which can be described at compile time and also somewhat
> independently at run time. For example, one can instantiate a state
> machine class multiple times within a containing state machine class.
> However, in that case the instantiations are part of a containing
> abstract value. This is similar to instantiating an abstract sub-
> circuit value within a containing abstract circuit value, and not to
> be confused with a physical instantiation (or "appearance") of a
> circuit in time and space.- Hide quoted text -
>
> - Show quoted text -
none Reinier Post
>What I'd like to see is a way that an OO programming language could work
>with data defined according to a relational schema. The big problem seems
>to be that OO doesn't have a good way of describing sets of objects in such
>a way that an operation on the set can be resolved down to a series of
>operations on the elements.
Some stupid OO languages didn't make this easy. But that has changed.
Iterators/enumerators and generics are the standard way of working
with collection now in C++, Java, C#. They're going further and further.
Take a look at LINQ.
--
Reinier
none Reinier Post
>[...] OO always needs another paradigm to ride,
>since it isn't a model of computation but a broken type system mixed
>with a module system. [...]
You mean abstract data types?
OO adds inheritance; is that where it breaks?
(BTW I agree with your criticism of inheritance.)
--
Reinier
David BL
> On Jul 23, 8:09 pm, David BL <davi...@iinet.net.au> wrote:
>
> > On Jul 23, 6:50 pm, Brian <br...@selzer-software.com> wrote:
>
> <snip>
>
> > > It may again be splitting hairs, but I would argue that it is the
> > > possible sets of field values rather than the possible states that can
> > > be determined independently, from the standpoint that a state is a set
> > > of field values /for/ a particular state machine and thus cannot be
> > > divorced from it.
>
> > Some definitions of an abstract state machine don't have any concept
> > of "field values". E.g. sometimes a state machine is defined by an
> > abstract set of states, a transition function etc.
>
> So? Isn't a set of values still a value?
My point is that you are complicating the discussion by introducing
the term 'fields'. For example, what does that mean exactly for an
object with no member variables and its state is associated with I/O
to a hardware clock based on a crystal oscillator and binary counter?
> > > For there to be a state requires first that there
> > > be a state machine!
>
> > That makes it difficult to talk about a state machine 'class' (using
> > OO speak). For example I may want to use {0,1,2,3} to represent a set
> > of possible states for a class of state machine, and write proofs
> > about behaviour of all run time instances of that class (before I've
> > even run the program).
>
> I don't see how treating states as mappings between the domain of
> objects of a particular type and the domain of possible values for
> those objects would make it any more difficult to talk about a state
> machine 'class.'
An object class is not a domain of objects. You can't form sets over
things that exist physically in time and space. The whole point of
the axioms of ZFC is to clearly define what is and isn't a set and in
its purest form the only permitted elements of sets are themselves
sets. Even though that assumption can be lifted, sets (and therefore
their elements) are *always* pure mathematical constructs divorced
from the physical.
What exactly do you mean by possible values for an object and how do
these values differ from states? You make it sound like objects are
always variables that hold values. That's one of the common
confusions about OO and the meaning of "encapsulation". In OO an
object is an identifiable instance of a state machine that exists in
time and space, that doesn't necessarily represent a variable that
holds a value.
Conversely, a variable can always be regarded as a very simple kind of
state machine (and in that sense is an object). In OO it is normal to
assume that a variable has a type defining the set of possible values
that it may hold, and all transitions between these 'states' (where
each state is associated with each value of that type) are equally
acceptable. That indeed is why a circle variable is not an ellipse
variable. BTW it is curious that some OO proponents argue that the
solution is to disallow mutative methods on the ellipse class but
forget about the assignment operator.
Ok. However if you want to prove that objects necessarily have
distinct sets of states you need to provide precise definitions of
terms like 'object' and 'state', and show how the result follows from
those definitions. I think you will find that your definition begs
the question.
Pure mathematical descriptions of state machines treat the possible
states as a mathematical set which immediately implies that the states
are divorced from space and time, and in OO speak relate to a class
(i.e. mathematical) not an object (i.e. physical).
I think our difference of opinion stems from your willingness to blur
the distinction between mathematical constructs and physical entities.
As I see it, an object is a uniquely identifiable physical
"manifestation" or "instantiation" of a class, and a class defines an
abstract state machine with abstractly defined states. It is
therefore possible for distinct objects of the same class to be deemed
to be in the same (abstract) state.
Cimode
> Reinier
Nilone
> Nilone wrote:
> >[...] OO always needs another paradigm to ride,
> >since it isn't a model of computation but a broken type system mixed
> >with a module system. [...]
>
> You mean abstract data types?
What I said there is confused and inaccurate. State machines
obviously are a model of computation.
OO classes are used to create data types, since encapsulation,
constructors and attributes are necessary features to create data
types. However, it fails as a type system since it allows subtypes to
be defined that breaks the original type. It also allows for the
creation of reference types, which is an oxymoron.
>
> OO adds inheritance; is that where it breaks?
> (BTW I agree with your criticism of inheritance.)
Implementation inheritance copies executable code across the interface
of the class and invites programmers to assume more than promised by
the interface.
My rant was against OO classes when used as a type system, although my
sloppy use of the term OO made it seem like more.
Nilone
> OO classes are used to create data types, since encapsulation,
> constructors and attributes are necessary features to create data
> types. However, it fails as a type system since it allows subtypes to
> be defined that breaks the original type. It also allows for the
> creation of reference types, which is an oxymoron.
I mean mutable types, not reference types.
Brian
Are you saying that the domain of discourse cannot consist of both
mathematical constructs and physical entities?
> As I see it, an object is a uniquely identifiable physical
> "manifestation" or "instantiation" of a class, and a class defines an
> abstract state machine with abstractly defined states. It is
> therefore possible for distinct objects of the same class to be deemed
> to be in the same (abstract) state.- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
David BL
> Are you saying that the domain of discourse cannot consist of both
> mathematical constructs and physical entities?
What do you mean by the domain of discourse (in a discussion about
state machines)?
Brian
The purpose of state machines is to model behavior exhibited by
concrete objects--that is, things that can have a location in time or
space. I should think that in order to model the behavior of concrete
objects, one must first be able to discuss them.
David BL
That depends on what you mean exactly. For example, OO source code
listings don't refer to the computers on which they execute (never
mind particular objects).
David BL
On this newsgroup, the word "type" nearly always means "data type",
and not a type of state machine (such as an abstraction of an output
stream). IMO it is important and useful to see that there are indeed
two fundamentally different kinds of types (and hence two distinct
kinds of type hierarchies).
1) Data types: Subtyping should follow the D&D subtype as constraint
approach. Data types always support comparison operators and
assignment to variables of that type.
2) State machine "types": Subtyping should follow LSP. LSP by
definition means substitutability of one type of state machine for
another.
It is possible to think of variables that hold values to be simple
state machines. That fact has tricked much of the OO community into
thinking that proper support for 2) makes 1) redundant. However, in
actual fact 2) is a very poor approach for representing data types.
The big problem is that subtype relationships amongst data types don't
map to subtype relationships on the variables that hold them. Most OO
programmers don't realise what they're missing. It's not just circle/
ellipse cases. For example they miss out on union types, and
therefore the basis for algebraic data types. The effect in practise
is that nested data types are constructed using dynamic variables and
pointers, making the code complex and verbose.
I think OO languages should distinguish these two independent type
hierarchies, and even go as far as demanding comparison and assignment
operators on data types and prohibiting them on state machine types.
Some OO languages only appear to make this distinction. E.g. C# has
value types versus reference types. However some data types like
strings are reference types and the reference comparison operator is
hijacked to instead perform string value comparisons).
Brian
Strings may be reference types, but they are immutable and therefore
behave more like value types. I think they are only implemented as
reference types in order to optimize method calls: copying a huge
string onto the stack would take a lot more cpu cycles then copying
just a pointer into the heap, and implementing a method that returns a
string on the stack would require either that the stack frame to have
had preallocated the space required for the returned string or that
the method be able to resize its own stack frame. It is the fact that
instances of value types are immutable in the same way that strings
are immutable that sets them apart from instances of types that aren't.
Nilone
Well stated. I especially like the suggestion that languages should
separate the type hierarchies, which is what I've been trying to say,
although less successfully.
I'm concerned about your statement about LSP and subtyping state
machines. I just don't see how (or why) you would subtype a state
machine. I'll allow subtyping an interface and implementing a new
state machine for it.
LSP requires any property provable about objects of the base type to
be provable of objects of the derived type. Subtyping a state machine
would have little value, since you wouldn't be able to change any
behaviour - "any property provable about the base type" would include
its exact behaviour.
In order to substitute one state machine for another, and allow the
new machine to behave differently from the old, the calling code is
not allowed to assume anything beyond the method signatures declared
in the interface. For example, if you've got an interface for a
collection, and a Bag state machine that implements it, you can't even
assume that the machine will add an item when you tell it to, since
the Bag may be substituted with a Set state machine.
David BL
That's actually what I meant. A "type" of state machine is what you
are calling an "interface". E.g. a SeekableInputStream is a subtype
of a InputStream. It follows that a reference (to a state machine) of
type SeekableInputStream can be upcast to a reference of type
InputStream.
I think of types as completely divorced from implementation (for both
data types and state machine types).
> LSP requires any property provable about objects of the base type to
> be provable of objects of the derived type. Subtyping a state machine
> would have little value, since you wouldn't be able to change any
> behaviour - "any property provable about the base type" would include
> its exact behaviour.
I agree that subclassing a concrete class doesn't make much sense. It
is important to distinguish between:
a) state machine "type", which refers to interface definition (of
method signatures as well as contracted behaviours); and
b) state machine "implementation".
Class hierarchies confuse this distinction by defining both at the
same time. That being said I'm not too surprised that it's common
practise. Separating type and implementation can make for a lot of
repetition. In a language like C++ it also tends to defeat inlining.
Nilone
> On Jul 27, 4:02 pm, Nilone <rea...@gmail.com> wrote:
Limiting inheritance to just interface inheritance, even from concrete
classes, would solve that nicely.
Bob Badour
Huh? What the hell does an implementation feature have to do with
databases or theory or types?
Nilone
The conflation of fundamental concepts in OO classes causes the
persistent confusion about types that is evident among OO
programmers. I believe this is relevant in a group where types are a
central theme. Anyway, I think this branch of the conversation is
just about done.
Bob Badour
What makes you think OO classes are relevant in the first place?
Nilone
OO classes are believed and used to model types. Furthermore, the
original article about O/R mapping clearly showed the consequences of
a lack of understanding of fundamental concepts. "Relational
databases" are often blamed for these problems. By understanding the
problems and limits of OO classes, the nonsense about OODBMS can be
countered.
Bob Badour
I respectfully suggest one can counter it more directly with far fewer
words.
none Reinier Post
>On Jul 21, 8:09 pm, "Walter Mitty" <wami...@verizon.net> wrote:
>> "David BL" <davi...@iinet.net.au> wrote in message
>
>> > In OO, object identity is usually regarded as determined by object
>> > location and is independent of object state. That of course is very
>> > different to your first sentence above where you say you prefer to use
>> > the object's state as the basis for identification.
>>
>> Thanks for clearing that up. I should clear up that I'm thinking about
>> storing information about "entities" in an SQL database, and not about
>> storing that information inside objects in an object world. Some database
>> designers attempt to copy the OO paradigm and try to assign each object
>> (what I refer to as an "entity") an OID. The OID is usually the first
>> column in its table, and is generally the primary key. Foreign key
>> references to an OID are generally used just as if they were pointers in a
>> world that's based on pointers.
>In OO, objects are state machines, not "entities" about which we may
>want to record information.
Now you're exaggerating. In (class-based) OO, classes are
abstract data types, that *can* be used to model stateful objects,
(e.g. state machines), but objects can be stateless just as well.
This is why an OO language is general purpose in nature.
>I have no idea why an OO programmer would want to pretend that
>employees, companies, departments, teachers or courses are state
>machines running on their computer! It's a ridiculous suggestion.
Then don't suggest it. An OO programmer would typically model
the static aspects of employees, etc., in stateless objects,
and dynamics (e.g. enrollment procedures, hiring procedures)
in stateful objects.
>It's also silly for an OO programmer to think that an element of a set
>of tuples recorded in a relvar represents a state machine.
Technically, it is. Every value of the tuple is a state.
But the transitions are trivial (no transition constraints).
Unless you do have transition constraints, of course,
which is when we start to use the term 'state machine'.
[...]
>> I don';t think it matters whether
>> the memory space is in RAM or on disk. And the address provided by apointer
>> can go through one or more mapping operations before finally resolving down
>> to a physical address.
>
>Well said.
I think this part of the discussion is a red herring.
The association of identity with physical implementation
is historically understandable but unnecessary.
Identity of terms can be supported as a modeling language feature
on any level of abstraction. I think both of you have made good
arguments why it makes sense to do so. (I try to point it out
when you go overboard, which seems to happen in places,
but I do support the premise.)
--
Reinier
none Reinier Post
Aren't those problems caused by the use of mutability
rather than OO inheritance? Of course subtypes can break
the original type, but developers aren't supposed to do that.
What alternative to inheritance do you propose for sharing
function implementations across objects of different but related types,
and how is it any safer?
--
Reinier
none Reinier Post
[...]
>In the OO world, objects are instances of reference types. The location
>of an object can change over its lifetime, but what is used to
>reference each object, the object identifier, doesn't.
It depends on what you mean by that.
Different identifiers can be used to point to the same object.
That is a defining characteristic of objects.
>It may be
>splitting hairs, but there is a distinct difference between 'identity'
>and 'the identity' in that 'identity' is a binary relation between
>objects in the universe that denotes /is identical to/, but 'the
>identity' of an object is that essential property (unary relation)
>which distinguishes it from all other objects (its haecceity) and
>which is embodied by an object identifier or by a proper name (in the
>logical sense).
I think this is utterly mistaken, regardless of whether you're referring
to logic or to or OO programming. Identity is never a relationship
between objects, but between identifiers that denote (refer to) objects.
And haecceity is not a property.
>The identity of an object is determined
>(functionally) by its object identifier but can also be determined by
>its current state in the same way that a relation schema can have more
>than one key. An object representing a particular serialized part can
>be identified by its object identifier as well as by the part's serial
>number, or by its position on the assembly line relative to all other
>similar parts on the line, which could change over time (for example,
>the part in front of it may have been scrapped).
Here I agree with your point that objects can also be identified
by other expressions than atomic identifiers.
--
Reinier
Brian
> Brian wrote:
>
> [...]
>
> >In the OO world, objects are instances of reference types. The location
> >of an object can change over its lifetime, but what is used to
> >reference each object, the object identifier, doesn't.
>
> It depends on what you mean by that.
> Different identifiers can be used to point to the same object.
> That is a defining characteristic of objects.
>
> >It may be
> >splitting hairs, but there is a distinct difference between 'identity'
> >and 'the identity' in that 'identity' is a binary relation between
> >objects in the universe that denotes /is identical to/, but 'the
> >identity' of an object is that essential property (unary relation)
> >which distinguishes it from all other objects (its haecceity) and
> >which is embodied by an object identifier or by a proper name (in the
> >logical sense).
>
> I think this is utterly mistaken, regardless of whether you're referring
> to logic or to or OO programming. Identity is never a relationship
> between objects, but between identifiers that denote (refer to) objects.
I suggest you bone up on Leibniz.
> And haecceity is not a property.
Yes it is. Is not the sum of all qualitative properties also a
property?
toby
> On Jul 22, 7:43 pm, Tegiri Nenashi <TegiriNena...@gmail.com> wrote:
>
>
>
> > On Jul 22, 5:29 am, Nilone <rea...@gmail.com> wrote:
>
> > > On Jul 20, 5:51 pm, "Walter Mitty" <wami...@verizon.net> wrote:
>
> > > > I've known for quite some time that better minds than mine have gone astray
> > > > in the attempt to overcome the object relational mismatch. Just last week,
> > > > I ran across an article that outlines the O-R mapping problem better than I
> > > > ever could.
>
> > > > The article is called "The Vietnam of Computer Science", and here's a
> > > > pointer:
>
> > > >http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science...
>
> > > > The article devotes rather too much time to exploring the analogy between
> > > > the Vietnam war and ORM attempts. And as the article admits, all analogies
> > > > eventually fail. Leaving that aside, I think the survey of problems
> > > > encountered in crossing the divide is excellent.
>
> > > > I want to draw particular attention to a heading entitled "Entity Identity
> > > > Issues". Reading this section gave me a better understanding of the
> > > > disconnect between me and Brian Seltzer over matters concerning entity and
> > > > identity. My own view of identity is colored by my own experience. And
> > > > that experience includes some practical work with relational databases,
> > > > preceded by a little formal learning in that area and 20 years of work as a
> > > > programmer. Unfortunately, none of that work included object oriented
> > > > programming.
>
> > > > Anyway, my view of identity (or of identification, if you prefer) is that an
> > > > object's state is all we have to go on as the basis for identification. In
> > > > particular, an object's location (as specified by a pointer) or its
> > > > trajectory (a history of pointers over time) are unavailable for purposes of
> > > > identification. This view of identity fits pretty comfortably into the
> > > > relional model, but it runs afoul of object oriented thinking at least two
> > > > important ways. Frst, if an object can conceal part of its state
> > > > (encapsulation), then it necessarily can conceal some of what needs to be
> > > > known to identify it. Second, if two objects are identical in state, then
> > > > they are the same object, even if they differ in location (at the same point
> > > > in time). I'll call this the "Doppelganger effect".
>
> > > > When I see an SQL table with two different rows in one table that cannot be
> > > > distinguished by their contents, my reaction is that the database designer
> > > > made a mistake. Failing in that, the database updaters should have been
> > > > more careful. Cases where duplication is intentional and carries
> > > > significant information strike me as a misuse of SQL, and a misunderstanding
> > > > of the relational model.
>
> > > > The above doesn't pretend to explain Brian's view. But I think it sheds a
> > > > little light on why I see things the way I do.
>
> > > > Again, I recommend the article cited above.
>
> > > The article states: 'The opposite approach--a "relational-only"
> > > approach--is almost nonsensical to consider, given the technology of
> > > the day at the time this was written'
>
> > > It sounds as if it just might be doable. Not like a D language, but
> > > like a DBMS with support for executing certain forms of data (since
> > > code is just another type of data, lisp and prolog proved that). All
> > > functions are relations, right? So can a functional programming
> > > paradigm be embedded in the relational model? Is there a relational
> > > model of computation? Just wondering...
>
> > IMO function viewed as a relation offers too little insight to be
> > practically useful (yet). Function composition is relational join
> > (followed by projection of intermediate attributes) -- that is about
> > it. What is recursion from relational perspective?
>
> > I would suggest that the theory of binary relations (aka Relation
> > Algebra) is more useful in computational world. Function composition
> > is the exact relational composition (join). Roland Backhouse pioneered
> > this direction, and J.N.Oliveira leaning it more towards databases...
>
> Yes, that's what I was looking for. Function composition is join, and
> then function application would be selection, right? The domain of
> the function is the propositional condition that restricts the
> selection, while the codomain would be the projection of the resulting
> set of tuples. Recursive queries would substitute the result set into
> the the selection condition (of course they would have to be the same
> type). Recursively defined relations would produce infinite sets.
> Any more references or information in this line?
>
> I looked at some pages on relation algebra, but it's still beyond me,
> I'll keep working at it, thanks for the info.
For some discussion of functions & relational theory you might want to
look in,
http://www.abebooks.com/servlet/SearchResults?an=date&sts=t&tn=logic
(yes this is another title from DBDebunk book list).
Nilone
Types define values. Values aren't mutable, since mutability implies
a persistent identity beyond the value itself. As soon as you have
mutability, you have a state machine, and subtyping state machines is
a problem. Subtyping an interface and creating a new state machine
for it is fine.
Take a look at http://alistair.cockburn.us/Constructive+deconstruction+of+subtyping
According to this, subtyping is possible for values (the R usage
envelope) and single-user state machines (the S envelope). Since
classes are reference types, single-user state machines can't be
assumed. As such, I don't consider subtyping of state machines to be
viable. Behavioural subtyping is an active research field, but I'm
not aware of a general solution yet.
If you need the same functions in different state machines, create an
instance of the base machine and use its function, or create a
function library which can be used by both.
Nilone
> (yes this is another title from DBDebunk book list).
Thanks, I'll check it out.
David BL
> David BL wrote:
> >On Jul 21, 8:09 pm, "Walter Mitty" <wami...@verizon.net> wrote:
> >> "David BL" <davi...@iinet.net.au> wrote in message
>
> >> > In OO, object identity is usually regarded as determined by object
> >> > location and is independent of object state. That of course is very
> >> > different to your first sentence above where you say you prefer to use
> >> > the object's state as the basis for identification.
>
> >> Thanks for clearing that up. I should clear up that I'm thinking about
> >> storing information about "entities" in an SQL database, and not about
> >> storing that information inside objects in an object world. Some database
> >> designers attempt to copy the OO paradigm and try to assign each object
> >> (what I refer to as an "entity") an OID. The OID is usually the first
> >> column in its table, and is generally the primary key. Foreign key
> >> references to an OID are generally used just as if they were pointers in a
> >> world that's based on pointers.
> >In OO, objects are state machines, not "entities" about which we may
> >want to record information.
>
> Now you're exaggerating. In (class-based) OO, classes are
> abstract data types, that *can* be used to model stateful objects,
> (e.g. state machines), but objects can be stateless just as well.
> This is why an OO language is general purpose in nature.
I want to clarify what you mean by stateless objects. Note firstly
that objects with no members or only immutable members can be deemed
to have a single state. It's not clear to me whether that means they
are "stateless". Also can't they be regarded as trivial state
machines? Note furthermore that objects of classes with no member
variables that implement abstract interfaces normally have type
information in order to support dynamic polymorphism. Do you regard
such objects as stateless?
Also what exactly do you mean by an abstract data type? For example,
is an abstract interface for an output stream an ADT? I would expect
an ADT to be limited to types where it can be assumed that objects of
that type are deemed to be variables that hold an abstract value
(that's what a *data* type is). That makes me think that all classes
define types and/or implementations of abstract state machines but
only some do so for ADTs.
> >I have no idea why an OO programmer would want to pretend that
> >employees, companies, departments, teachers or courses are state
> >machines running on their computer! It's a ridiculous suggestion.
>
> Then don't suggest it.
The first book I ever read on OO (back in the early 90's) introduced
the subject using a hierarchy of employee classes - and it talked
about how it's useful to have a polymorphic GetPay() method, e.g. so a
sales employee can override to add a commission on top of the
inherited base salary.
I now consider such books to be ridiculous because they are founded on
an approach which lacks conceptual integrity. For example, objects
have identity as state machines but not as humans, so logically one
should be willing to create any number of objects that model the
*same* employee (perhaps in different ways). This idea of 1:1
mapping informal entities in the real world to objects within an
abstract machine seems completely arbitrary to me because it is
founded on a pretence (that an object actually *is* the external
entity that it models).
When I use OO, I think of an object has having a well defined identity
and role within the abstract machine. I try to use class names that
reflect that role. In that sense a class called "Employee" is
laughable.
> An OO programmer would typically model
> the static aspects of employees, etc., in stateless objects,
> and dynamics (e.g. enrollment procedures, hiring procedures)
> in stateful objects.
Are you saying that OO is used to process the information, but not to
record the information?
> >It's also silly for an OO programmer to think that an element of a set
> >of tuples recorded in a relvar represents a state machine.
>
> Technically, it is. Every value of the tuple is a state.
> But the transitions are trivial (no transition constraints).
> Unless you do have transition constraints, of course,
> which is when we start to use the term 'state machine'.
I don't see that as the issue. I have no problem calling a variable
that supports arbitrary assignment a simple (but rather uninteresting)
kind of state machine.
The problem I see is that most generally tuples in a set don't have an
immutable identifier allowing them to be mapped to a variable in a
useful manner. For example, how would a set<int> be mapped to a set
of variables (by analogy to an O/R mapping)? How do you efficiently
locate a variable for a given value? It would seem necessary to
record a map from int to the address of the associated variable. When
a variable is updated, it is necessary to update the map. However
what happens if one of the variables is changed so it holds the same
value as one of the other variables? Does it suddenly disappear? How
does the code avoid access violations?
> >> I don';t think it matters whether
> >> the memory space is in RAM or on disk. And the address provided by apointer
> >> can go through one or more mapping operations before finally resolving down
> >> to a physical address.
>
> >Well said.
>
> I think this part of the discussion is a red herring.
> The association of identity with physical implementation
> is historically understandable but unnecessary.
> Identity of terms can be supported as a modeling language feature
> on any level of abstraction. I think both of you have made good
> arguments why it makes sense to do so. (I try to point it out
> when you go overboard, which seems to happen in places,
> but I do support the premise.)
Agreed.
Bob Badour
> On Jul 28, 1:21 am, rp@raampje.(none) (Reinier Post) wrote:
>
>>Nilone wrote:
>>
>>>On Jul 25, 10:34 am, Nilone <rea...@gmail.com> wrote:
>>>
>>>>OO classes are used to create data types, since encapsulation,
>>>>constructors and attributes are necessary features to create data
>>>>types. However, it fails as a type system since it allows subtypes to
>>>>be defined that breaks the original type. It also allows for the
>>>>creation of reference types, which is an oxymoron.
>>
>>>I mean mutable types, not reference types.
>>
>>Aren't those problems caused by the use of mutability
>>rather than OO inheritance? Of course subtypes can break
>>the original type, but developers aren't supposed to do that.
>>What alternative to inheritance do you propose for sharing
>>function implementations across objects of different but related types,
>>and how is it any safer?
>
> Types define values. Values aren't mutable, since mutability implies
> a persistent identity beyond the value itself. As soon as you have
> mutability, you have a state machine, and subtyping state machines is
> a problem. Subtyping an interface and creating a new state machine
> for it is fine.
Forget state machines. As soon as you have mutability, you have a
variable. Leave it at that.
Nilone
Nah, that doesn't suit me.
Bob Badour
Fair enough. If you are only here to waste time, plonk!
none Reinier Post
>On Jul 27, 7:24�pm, rp@raampje.(none) (Reinier Post) wrote:
>> Brian wrote:
>>
>> [...]
>> >It may be
>> >splitting hairs, but there is a distinct difference between 'identity'
>> >and 'the identity' in that 'identity' is a binary relation between
>> >objects in the universe that denotes /is identical to/, but 'the
>> >identity' of an object is that essential property (unary relation)
>> >which distinguishes it from all other objects (its haecceity) and
>> >which is embodied by an object identifier or by a proper name (in the
>> >logical sense).
>>
>> I think this is utterly mistaken, regardless of whether you're referring
>> to logic or to or OO programming. �Identity is never a relationship
>> between objects, but between identifiers that denote (refer to) objects.
>
>I suggest you bone up on Leibniz.
That's a bit difficult, my Latin is extremely poor.
But I think I've identified the source of this misunderstanding: page 146 of
'Relational database: selected writings' (Addison-Wesley 1989) by C. Date.
>> And haecceity is not a property.
>
>Yes it is. Is not the sum of all qualitative properties also a
>property?
It depends on what you mean by that. The potential problem is not
in considering a sum of properties as a property, but in the 'all'.
If you define the haeccity of an entity type as the collection of all
qualitative properties we distinguish for that object type, then of course
haeccity can be regarded as a property of such objects. It just becomes
another way of saying that all properties of a relation form a key.
I doubt this is what you mean.
If you define it as all qualitative properties that can conceivably be
distinguish for a particular object type, then you start running into
circles: for every property you consider that adds distinctions between
objects, you will need to decide whether the distinction is an essential
characteristic of the object type itself, or of an object type that is
related to the object type you're describing. This is a modeling decision,
not something that can be extracted from Mother Nature.
--
Reinier
none Reinier Post
>I'm opposing OO as implemented in the current suite of mainstream
>languages - more specifically, I'm opposing the class systems of
>mainstream languages. I have no problem with state machines.
Then how do you express them? How do you express state change?
--
Reinier
Brian
> Brian wrote:
> >On Jul 27, 7:24 pm, rp@raampje.(none) (Reinier Post) wrote:
> >> Brian wrote:
>
> >> [...]
> >> >It may be
> >> >splitting hairs, but there is a distinct difference between 'identity'
> >> >and 'the identity' in that 'identity' is a binary relation between
> >> >objects in the universe that denotes /is identical to/, but 'the
> >> >identity' of an object is that essential property (unary relation)
> >> >which distinguishes it from all other objects (its haecceity) and
> >> >which is embodied by an object identifier or by a proper name (in the
> >> >logical sense).
>
> >> I think this is utterly mistaken, regardless of whether you're referring
> >> to logic or to or OO programming. Identity is never a relationship
> >> between objects, but between identifiers that denote (refer to) objects.
>
> >I suggest you bone up on Leibniz.
>
> That's a bit difficult, my Latin is extremely poor.
> But I think I've identified the source of this misunderstanding: page 146 of
> 'Relational database: selected writings' (Addison-Wesley 1989) by C. Date.
>
Unfortunately, I don't have access to that book.
> >> And haecceity is not a property.
>
> >Yes it is. Is not the sum of all qualitative properties also a
> >property?
>
> It depends on what you mean by that. The potential problem is not
> in considering a sum of properties as a property, but in the 'all'.
>
> If you define the haeccity of an entity type as the collection of all
> qualitative properties we distinguish for that object type, then of course
> haeccity can be regarded as a property of such objects. It just becomes
> another way of saying that all properties of a relation form a key.
I think we're talking across purposes. You seem to be saying that
properties belong to an object type, when in fact they belong to the
objects themselves. For example, 'being red' is a property, but is
'being red or being blue or being yellow' a property, or is it a
predicate?
> I doubt this is what you mean.
>
> If you define it as all qualitative properties that can conceivably be
> distinguish for a particular object type, then you start running into
> circles: for every property you consider that adds distinctions between
> objects, you will need to decide whether the distinction is an essential
> characteristic of the object type itself, or of an object type that is
> related to the object type you're describing. This is a modeling decision,
> not something that can be extracted from Mother Nature.
>
> --
> Reinier- Hide quoted text -
>
> - Show quoted text -
Nilone
I realize that the mechanisms of OO classes are suited (I suppose I'll
yield to the point of saying well-suited) to creating state machines.
I still believe that some of these mechanisms (e.g. implementation
inheritance) are problematic for this purpose.
none Reinier Post
>> It depends on what you mean by that. �The potential problem is not
>> in considering a sum of properties as a property, but in the 'all'.
>>
>> If you define the haeccity of an entity type as the collection of all
>> qualitative properties we distinguish for that object type, then of course
>> haeccity can be regarded as a property of such objects. It just becomes
>> another way of saying that all properties of a relation form a key.
>
>I think we're talking across purposes. You seem to be saying that
>properties belong to an object type, when in fact they belong to the
>objects themselves. For example, 'being red' is a property, but is
>'being red or being blue or being yellow' a property, or is it a
>predicate?
I can't tell exactly what you mean by a property.
I'll keep guessing until you define it in more detail.
My guess was that by a 'qualitative property' you mean something
like a relational attribute, which applies in principle to
each object of a particular type within the context of a particular
conceptual model used for a particular purpose. You may also mean
anything that can be said about an object at all, without having any
sort of categorization of objects into types in mind. However, that
way properties (and objects themselves) become a lot fuzzier in meaning.
How do the red colors of this tube of toothpaste compare to the red
colors in GraphViz diagrams? Just an example.
--
Reinier
none Reinier Post
So what is your alternative for expressing dynamics (behavior)
in a disciplined,maintainable way? Is a big bag of procedures
that can query and update arbitrary data as they please *better*?
--
Reinier
none Reinier Post
[...]
>> >In OO, objects are state machines, not "entities" about which we may
>> >want to record information.
>>
>> Now you're exaggerating. In (class-based) OO, classes are
>> abstract data types, that *can* be used to model stateful objects,
>> (e.g. state machines), but objects can be stateless just as well.
>> This is why an OO language is general purpose in nature.
>
>I want to clarify what you mean by stateless objects. Note firstly
>that objects with no members or only immutable members can be deemed
>to have a single state. It's not clear to me whether that means they
>are "stateless".
Immutable. No variables. Constructed and yielded, but never changed.
I believe this is becoming more and more popular.
>Also can't they be regarded as trivial state machines?
Single-state machines, perhaps.
A less extreme alternative is to use classes to define traditional
data types, atomic or structured. *Only* variables. Trivial
state machines, with the states being the values of the variables.
This programming style is called 'procedural' or 'imperative',
it predates OO and relational databases and it's not going to go away.
Finally, ADTs can be used to express nontrivial state machines,
i.e. in which dynamic constraints (formal or informal)
are considered part of the specification.
>Note furthermore that objects of classes with no member
>variables that implement abstract interfaces normally have type
>information in order to support dynamic polymorphism. Do you regard
>such objects as stateless?
No. And I agree with Nilone that polymorphism on state machines
is pretty hairy.
>Also what exactly do you mean by an abstract data type? For example,
>is an abstract interface for an output stream an ADT?
I believe most people would call it that, including the intended behavior.
In an OO programming language, you don't typically specify behavior
within the language. E.g. an interface IStack with methods
push, pop and isempty doesn't usually specify within the language
that an implementation is supposed to behave like a FIFO rather than a
LIFO, yet this is probably the intent of whoever wrote that interface.
>I would expect
>an ADT to be limited to types where it can be assumed that objects of
>that type are deemed to be variables that hold an abstract value
>(that's what a *data* type is). That makes me think that all classes
>define types and/or implementations of abstract state machines but
>only some do so for ADTs.
For me it's the reverse: all classes implement ADTs,
whereas only some define data types.
>> >I have no idea why an OO programmer would want to pretend that
>> >employees, companies, departments, teachers or courses are state
>> >machines running on their computer! It's a ridiculous suggestion.
>>
>> Then don't suggest it.
>
>The first book I ever read on OO (back in the early 90's) introduced
>the subject using a hierarchy of employee classes - and it talked
>about how it's useful to have a polymorphic GetPay() method, e.g. so a
>sales employee can override to add a commission on top of the
>inherited base salary.
Looks like a good illustration of the mechanism to me.
>I now consider such books to be ridiculous because they are founded on
>an approach which lacks conceptual integrity. For example, objects
>have identity as state machines but not as humans, so logically one
>should be willing to create any number of objects that model the
>*same* employee (perhaps in different ways).
I don't follow. What does it mean for an object to have identity as a
state machine? What kind of mapping do you have in mind between objects
in object models in computer memory and humans?
>This idea of 1:1
>mapping informal entities in the real world to objects within an
>abstract machine seems completely arbitrary to me because it is
>founded on a pretence (that an object actually *is* the external
>entity that it models).
But object models don't necessarily come with such pretenses.
We don't need to map objects to you or me, we can map them to GUI objects
on the computer screen, or printers attached via the network, or persons
walking around in SimWhatever, etcetera.
>When I use OO, I think of an object has having a well defined identity
>and role within the abstract machine. I try to use class names that
>reflect that role. In that sense a class called "Employee" is
>laughable.
The only reason it's laughable is the normal direction of control:
we can't usually *control* opr *observe* an employee through an
Employee object in an object model. As soon as we all have our
electrodes installed, it will not be laughable at all.
>> An OO programmer would typically model
>> the static aspects of employees, etc., in stateless objects,
>> and dynamics (e.g. enrollment procedures, hiring procedures)
>> in stateful objects.
>
>Are you saying that OO is used to process the information, but not to
>record the information?
I'm saying that processing, behavior, business logic, also needs to go
somewhere, in an organized, maintainable way; database models can't
express it, and OO models typically provide space for it.
Unless you don't use that space in your design, of course,
and treat objects as structured variables, defeating their purpose.
>The problem I see is that most generally tuples in a set don't have an
>immutable identifier allowing them to be mapped to a variable in a
>useful manner.
Now you're reversing problem and solution - variables are the problem!
>For example, how would a set<int> be mapped to a set
>of variables (by analogy to an O/R mapping)?
Why would you want to do that? The fewer variables, the better!
>How do you efficiently
>locate a variable for a given value? It would seem necessary to
>record a map from int to the address of the associated variable. When
>a variable is updated, it is necessary to update the map. However
>what happens if one of the variables is changed so it holds the same
>value as one of the other variables? Does it suddenly disappear? How
>does the code avoid access violations?
Yes, aliasing is a problem. The solution is to use as few references
as possible. That's what the ADTs are for.
--
Reinier
Nilone
I've already accepted that OO classes are appropriate for creating
state machines, hence I'm not offering alternatives. Note that "a big
bag of procedures that can query and update arbitrary data as they
please" is an unfair characterization of procedural programming,
similar to "a big bag of objects that can query and update each other
as they please".
Nilone
> David BL wrote:
>
> [...]
>
> >> >In OO, objects are state machines, not "entities" about which we may
> >> >want to record information.
>
> >> Now you're exaggerating. In (class-based) OO, classes are
> >> abstract data types, that *can* be used to model stateful objects,
> >> (e.g. state machines), but objects can be stateless just as well.
> >> This is why an OO language is general purpose in nature.
>
> >I want to clarify what you mean by stateless objects. Note firstly
> >that objects with no members or only immutable members can be deemed
> >to have a single state. It's not clear to me whether that means they
> >are "stateless".
>
> Immutable. No variables. Constructed and yielded, but never changed.
> I believe this is becoming more and more popular.
Stateless is a misnomer. Immutable is descriptive. I prefer to call
them values, and the classes that create them, types.
>
> >Also can't they be regarded as trivial state machines?
>
> Single-state machines, perhaps.
I prefer to keep the two separate. Subtyping is viable for types, but
not for state machines in general. Implementation inheritance is
suitable for types, but not for state machines in general. Interface
polymorphism is suitable for state machines, not for types. State
machines have methods and state, types have attributes.
>
> A less extreme alternative is to use classes to define traditional
> data types, atomic or structured. *Only* variables. Trivial
> state machines, with the states being the values of the variables.
> This programming style is called 'procedural' or 'imperative',
> it predates OO and relational databases and it's not going to go away.
I know these objects as tuples or records, and think of them as a set
of variables.
>
> Finally, ADTs can be used to express nontrivial state machines,
> i.e. in which dynamic constraints (formal or informal)
> are considered part of the specification.
Huh? Classes *ARE* the ADTs which are used to express nontrivial
state machines.
>
> >Note furthermore that objects of classes with no member
> >variables that implement abstract interfaces normally have type
> >information in order to support dynamic polymorphism. Do you regard
> >such objects as stateless?
>
> No. And I agree with Nilone that polymorphism on state machines
> is pretty hairy.
When the concepts are clearly separated, the hairiness disappears.
Polymorphism for state machines is achieved via interface inheritance,
and you may only assume what the interface explicitly specifies. If
it doesn't specify semantic invariants, you can't just assume them.
>
> >Also what exactly do you mean by an abstract data type? For example,
> >is an abstract interface for an output stream an ADT?
>
> I believe most people would call it that, including the intended behavior.
> In an OO programming language, you don't typically specify behavior
> within the language. E.g. an interface IStack with methods
> push, pop and isempty doesn't usually specify within the language
> that an implementation is supposed to behave like a FIFO rather than a
> LIFO, yet this is probably the intent of whoever wrote that interface.
I wouldn't call an interface an ADT. ADTs (as described on Wikipedia,
among others) are state machines for (usually homogeneous) collections
of values.
>
> >I would expect
> >an ADT to be limited to types where it can be assumed that objects of
> >that type are deemed to be variables that hold an abstract value
> >(that's what a *data* type is). That makes me think that all classes
> >define types and/or implementations of abstract state machines but
> >only some do so for ADTs.
>
> For me it's the reverse: all classes implement ADTs,
> whereas only some define data types.
For me, classes can be used to implement state machines (which include
ADTs) OR data types OR interfaces. The last two requires specific
limits on how you define the class.
>
> >The first book I ever read on OO (back in the early 90's) introduced
> >the subject using a hierarchy of employee classes - and it talked
> >about how it's useful to have a polymorphic GetPay() method, e.g. so a
> >sales employee can override to add a commission on top of the
> >inherited base salary.
>
> Looks like a good illustration of the mechanism to me.
Implementation inheritance + overriding is a mistake.
<snip discussion of modeling employees>
When modeling real-world entities, you should understand the
difference between types, values, interfaces and state machines. If
you create an Employee type then you can create a Manager type which
is a subtype of it. If you create an Employee state machine then you
can have mutable state and behavior. If you create an Employee
interface then you can derive a Manager interface from it, but then
you can't reason about the behavior of polymorphic objects.
> >Are you saying that OO is used to process the information, but not to
> >record the information?
>
> I'm saying that processing, behavior, business logic, also needs to go
> somewhere, in an organized, maintainable way; database models can't
> express it, and OO models typically provide space for it.
You *can* express all knowledge of a state machine, including
behavior, in a relational database. I previously posted a link to a
paper that did exactly that. See
http://www.ohiolink.edu/etd/send-pdf.cgi/Punnam%20Pradeep%20Kumar.pdf?acc_num=kent1226606883
Since state machines are a model of computation, all behavior,
business logic, etc. could be expressed as such.
The failing is in current database management systems for being unable
to compile/translate your class into this form, and then to simulate/
execute these models. It is not a failing of database theory.
> Unless you don't use that space in your design, of course,
> and treat objects as structured variables, defeating their purpose.
>
> >The problem I see is that most generally tuples in a set don't have an
> >immutable identifier allowing them to be mapped to a variable in a
> >useful manner.
>
> Now you're reversing problem and solution - variables are the problem!
>
> >For example, how would a set<int> be mapped to a set
> >of variables (by analogy to an O/R mapping)?
>
> Why would you want to do that? The fewer variables, the better!
What's wrong with variables?
>
> >How do you efficiently
> >locate a variable for a given value? It would seem necessary to
> >record a map from int to the address of the associated variable. When
> >a variable is updated, it is necessary to update the map. However
> >what happens if one of the variables is changed so it holds the same
> >value as one of the other variables? Does it suddenly disappear? How
> >does the code avoid access violations?
>
> Yes, aliasing is a problem. The solution is to use as few references
> as possible. That's what the ADTs are for.
It is not references that are the problem, but references to shared
mutable objects. BTW, I believe your use of ADT here is what I would
call a tuple or record.
none Reinier Post
[...]
>> So what is your alternative for expressing dynamics (behavior)
>> in a disciplined,maintainable �way? �Is a big bag of procedures
>> that can query and update arbitrary data as they please *better*?
>>
>> --
>> Reinier
>
>I've already accepted that OO classes are appropriate for creating
>state machines, hence I'm not offering alternatives. Note that "a big
>bag of procedures that can query and update arbitrary data as they
>please" is an unfair characterization of procedural programming,
>similar to "a big bag of objects that can query and update each other
>as they please".
My question is: how do you propose to organize them?
Do you agree that some disciplining in how code can access objects
is required? What do you propose code should look like
(you write 'relational all the way', what does relational GUI
code look like - not that I can't imagine any).
--
Reinier
none Reinier Post
>Types define values. Values aren't mutable, since mutability implies
>a persistent identity beyond the value itself. As soon as you have
>mutability, you have a state machine, and subtyping state machines is
>a problem. Subtyping an interface and creating a new state machine
>for it is fine.
You are using the term 'type' in a different sense than OO languages
such as Java and C# do.
The issues with subtyping he points out are very well known among
OO developers, and I was well aware of the importance of the difference
between single-threaded and concurrent access, but I've never seen it
discussed so clearly. (Then again, I don't read OO literature.)
>According to this, subtyping is possible for values (the R usage
>envelope) and single-user state machines (the S envelope). Since
>classes are reference types, single-user state machines can't be
>assumed. As such, I don't consider subtyping of state machines to be
>viable. Behavioural subtyping is an active research field, but I'm
>not aware of a general solution yet.
Well, the most common 'solution' is not to formally define any
requirements on the behavior of classes or interfaces at all
but merely state them in comments and examples and hope for the best,
but I believe this is changing.
>If you need the same functions in different state machines, create an
>instance of the base machine and use its function, or create a
>function library which can be used by both.
But what if you need equivalent, but differently implemented functions?
That's what polymorphism is for.
--
Reinier
Nilone
Here is a rough description of a hypothetical type system for a
programming language. My terminology is based on C#, but the logic is
based on relational theory. Static GUIs are easy enough to describe
in a DB, the difficult part is describing dynamic behavior, which I
hope to achieve by associating functions and state machines with data
types (i.e. RM headings).
1. Data types
Structs and classes both allow for the creation of composite
structures of data types and functions. Declaration of data types
should be separated from memory allocation and variable semantics.
Composite data type are just the derivation of new data types from
existing data types via composition, projection (as in RM), extension
(addition of attributes) or constraint (covariant overriding).
Derivation via extension or constraint is called subtyping.
Attributes of a data type are named, and can be primitive data types
(bool, byte, short, int, long, float, double, date, etc), composite
data types, functions (derived attributes) or function-typed (i.e.
delegates).
2. Values
A value is data in memory associated with a type. Values are
immutable constructs, created by parametrized constructor functions.
Equality of values of compatible types is defined as equality of the
values of corresponding attributes.
3. State machines
A state machine is derived from a data type, and consists of a set of
methods which describe transitions between values of the associated
type. A state machines can define an interface, or implement one or
more existing interfaces.
Every instance of a state machine has an implicit variable containing
the state of that instance as a value of the associated type. In
addition, an instance of a state machine may hold references to
instances of other state machines.
State machines are initialized via a constructor method, which may be
parametrized. State machines may also define destructor methods.
4. Interfaces
An interface is a published data type, optionally with one or more
associated state machines, and optionally with limitations on access
by clients.
5. Variables
Variables hold values, instances of state machines, or references (to
values or instances of state machines). The contents of a variable is
determined by the assignment to the variable. Variables are mutable.
The contents of a variable is always passed as is.
6. Collections
Variables can be declared as homogeneous sets of values / state
machines / references. The usual semantics associated with sets
apply, in addition to selection/restriction by attributes.
Nilone
> Nilone wrote:
> >Types define values. Values aren't mutable, since mutability implies
> >a persistent identity beyond the value itself. As soon as you have
> >mutability, you have a state machine, and subtyping state machines is
> >a problem. Subtyping an interface and creating a new state machine
> >for it is fine.
>
> You are using the term 'type' in a different sense than OO languages
> such as Java and C# do.
That's not surprising. Most OO documentation and tutorials use the
term to indicate arbitrary classification or similarity. I use the
term to indicate a domain of values with defined semantics, and to the
construction of such a domain in a programming language. I'll stand
by my definition until I see a better one.
>
> >Take a look at
> >http://alistair.cockburn.us/Constructive+deconstruction+of+subtyping
>
> The issues with subtyping he points out are very well known among
> OO developers, and I was well aware of the importance of the difference
> between single-threaded and concurrent access, but I've never seen it
> discussed so clearly. (Then again, I don't read OO literature.)
>
> >According to this, subtyping is possible for values (the R usage
> >envelope) and single-user state machines (the S envelope). Since
> >classes are reference types, single-user state machines can't be
> >assumed. As such, I don't consider subtyping of state machines to be
> >viable. Behavioural subtyping is an active research field, but I'm
> >not aware of a general solution yet.
>
> Well, the most common 'solution' is not to formally define any
> requirements on the behavior of classes or interfaces at all
> but merely state them in comments and examples and hope for the best,
> but I believe this is changing.
>
> >If you need the same functions in different state machines, create an
> >instance of the base machine and use its function, or create a
> >function library which can be used by both.
>
> But what if you need equivalent, but differently implemented functions?
> That's what polymorphism is for.
Take a look at my other post. I believe the type system I described
there is properly polymorphic. If you give an example, I'll describe
it in terms of that system.
Nilone
create mutable objects based on them. Syntax is made up as I go
along.
type Point2D
{
int x, y;
Point2D(int _x, _y)
{
x = _x;
y = _y;
}
}
type Size2D
{
int width, height;
Size2D(int _w, _h)
{
width = _w;
height = _h;
}
}
type Rectangle
{
// Attributes of a type are public
Point2D position;
Size2D size;
// Only constructor can initialize value
Rectangle(int _x, _y, _w, _h)
{
position = new Point2D(_x, _y);
size = new Size2D(_w, _h);
}
// Read-only attributes only
int Area()
{
return size.width*size.height;
}
}
// A square is a rectangle
type Square : Rectangle
{
// Can't override Area()
// Constructor required to create new type
Square(int _x, _y, _s)
{
position = new Point2D(_x, _y);
size = new Size2D(_s, _s);
}
}
// Button interface exports button type and
// defines behavior for all button state machines
interface IButton
{
// All Buttons must implement Move
void Move(int newx, newy);
// Events are functions that must be implemented
// by client. Interfaces are bidirectional.
event Clicked();
}
// RectButton is a Rectangle-typed state machine
// with an IButton interface.
statemachine RectButton : IButton, Rectangle
{
RectButton(Rectangle r)
{
state = r;
}
// Implementing Move
void Move(int newx, newy)
{
state = new Rectangle(newx, newy, state.size.width,
state.size.height);
}
void Stretch(int addx, addy)
{
state = new Rectangle(state.position.x, state.position.y,
state.size.width+addx,
state.size.height+addy);
}
}
// SquareButton is a Square-typed state machine
// and inherits the interface of RectButton
statemachine SquareButton : RectButton, Square
{
SquareButton(Square s)
{
state = s
}
// Implementing Move
void Move(int newx, newy)
{
state = new Square(newx, newy, state.size.width);
}
void Stretch(int adds)
{
state.size = new Size2D(state.x2 + adds, state.y2 + adds);
}
}
void main()
{
RectButton rb = new RectButton(10, 10, 100, 50);
SquareButton sb = new SquareButton(20, 20, 70);
IButton b = rb;
b.move(40, 40);
b = sb;
b.move(60, 60);
rb.state = sb.state;
}
It is straightforward to create polymorphically compatible mutable
state machines with polymorphically compatible state. It also seems
to help to prevent faulty reasoning which would have been accepted in
traditional OO classes.
rpost
>BTW, I also came across the following article, which looks
>interesting:
>
>RELATIONAL MODEL FOR PROGRAM SEMANTICS
>http://www.ohiolink.edu/etd/send-pdf.cgi/Punnam%20Pradeep%20Kumar.pdf?acc_num=kent1226606883
I skimmed it, and I don't get it. The presentation is clear,
but I don't see that it's doing anything interesting or new.
It has nothing to do with the relational database model, which is
about recording information about the world in *finite* relations.
Tt defines the semantics of a program as a relation, noticing that
nondeterminism can be described this way, but it doesn't mention that
such relations are known in the literature as (state) transition systems
and have been used for this purpose since at least the early 1950s, and
probably decades earlier. It goes on about Hoare and Smythe orderings
on programs, but the significance doesn't become clear to me.
--
Reinier
none Reinier Post
>On Aug 8, 12:31�am, rp@raampje.(none) (Reinier Post) wrote:
>> Nilone wrote:
>> >Types define values. Values aren't mutable, since mutability implies
>> >a persistent identity beyond the value itself. �As soon as you have
>> >mutability, you have a state machine, and subtyping state machines is
>> >a problem. �Subtyping an interface and creating a new state machine
>> >for it is fine.
What you're describing I might call 'abstract data type'
but not just 'type'.
>> You are using the term 'type' in a different sense than OO languages
>> such as Java and C# do.
>
>That's not surprising. Most OO documentation and tutorials use the
>term to indicate arbitrary classification or similarity.
You're reading different documentation and tutorials than I have seen.
I don't think I've ever seen the term 'type' used in that way.
Aren't you referring to 'class'?
> I use the
>term to indicate a domain of values with defined semantics, and to the
>construction of such a domain in a programming language. I'll stand
>by my definition until I see a better one.
Try Luca Cardelli's:
http://lucacardelli.name/Papers/TypeSystems.pdf
[...]
>> But what if you need equivalent, but differently implemented functions?
>> That's what polymorphism is for.
>
>Take a look at my other post. I believe the type system I described
>there is properly polymorphic. If you give an example, I'll describe
>it in terms of that system.
OK.
--
Reinier
Nilone
> Nilone wrote:
> >On Aug 8, 12:31 am, rp@raampje.(none) (Reinier Post) wrote:
> >> Nilone wrote:
> >> >Types define values. Values aren't mutable, since mutability implies
> >> >a persistent identity beyond the value itself. As soon as you have
> >> >mutability, you have a state machine, and subtyping state machines is
> >> >a problem. Subtyping an interface and creating a new state machine
> >> >for it is fine.
>
> What you're describing I might call 'abstract data type'
> but not just 'type'.
I was contrasting (data) types with state machines, among which ADTs
can be counted. Abstract data types are models of behavior, for
example stacks and queues. Compare "data type" with "abstract data
type" in Wikipedia.
>
> >> You are using the term 'type' in a different sense than OO languages
> >> such as Java and C# do.
>
> >That's not surprising. Most OO documentation and tutorials use the
> >term to indicate arbitrary classification or similarity.
>
> You're reading different documentation and tutorials than I have seen.
> I don't think I've ever seen the term 'type' used in that way.
> Aren't you referring to 'class'?
Perhaps in the philosophical sense, but not in the programming sense.
I'm claiming that OO classes conflate different concepts, and that by
separating and understanding these concepts, the problems in OO can be
overcome.
>
> > I use the
> >term to indicate a domain of values with defined semantics, and to the
> >construction of such a domain in a programming language. I'll stand
> >by my definition until I see a better one.
>
> Try Luca Cardelli's:
>
> http://lucacardelli.name/Papers/TypeSystems.pdf
Cardelli seems to agree with me:
"A program variable can assume a range of values during the execution
of a program. An upper
bound of such a range is called a type of the variable. For example, a
variable x of type Boolean
is supposed to assume only boolean values during every run of a
program. If x has type Boolean,
then the boolean expression not(x) has a sensible meaning in every run
of the program."
And from the definition of terms:
"Type: A collection of values. ..."
none Reinier Post
>Here is a rough description of a hypothetical type system for a
>programming language. My terminology is based on C#, but the logic is
>based on relational theory. [...]
But it's essentially a restriction of C# or Java, isn't it?
You restrict inheritance.
I don't understand the significance of the distinction between
'state machines' and other reference types in your system.
--
Reinier
noyb
> Anyway, my view of identity (or of identification, if you prefer) is that an
To define the boundaries of the natural concept "object" isn't
easy in the real world. For example, what is a tornado? Even a
human is just a thermodynamic process occurring within an ill-
defined and ever-changing set of atomic particles. In the OO
community, the problem is finessed; the identity is assumed to
exist just as the identity of a human or a tornado is assumed
to exist; then the programmer makes use of the known behaviour
of their machines to make that assumption to appear as mostly
true.
The RM is a self-contained model, and as such, can circumscribe
the identity of a tuple, and it requires specifying a means to
identify every tuple.
> if two objects are identical in state, then
> they are the same object, even if they differ in location
On the other hand, it's both possible and expected that two
different running programs have a given tuple in memory at
the same time, or at the same time that the row still exists
in storage We like to pretend that all these instances are the
same tuple. We can get away with that pretense *only* because
of the fact that we manipulate the tuples only within the
confines of a DBMS that conforms to ACID restrictions.
Even if you use a definition of "object" which *does* have
formal semantics (as, for example, it does in Terry Halpin's
"Object Role Modeling"), concurrency still requires that we
create this pretense.
Terry's book "Information Modeling and Relational Databases"
presents Object Role Modeling (ORM2; an unfortunate conflict of
acronyms with O/RM) and compares it with various ER languages
and with UML class diagrams, showing the drawbacks of all the
languages. ORM2 is fact-oriented, which is isomorphic with RM
in the same way (and because) set theory and first-order logic
are isomorphic. ORM2 tools map to the relational model and
generate also SQL. It's a very important book that should be
read by everyone who has to design a database. Easy to read,
replete with good examples, but long... it's a big subject!
My derivative of ORM2, the Constellation Query Language, is a
controlled natural language which, as well as SQL, generates
object-oriented class libraries. These classes do not have the
same drawbacks as common object systems, because:
* every object is either a value or an entity
* values are identified by their lexical representation
* entities are identified by a set of one or more functional roles
* objects exist only within a Constellation
* a Constellation never contains a duplicate object
* an object cannot be created or destroyed, only asserted or denied
within a Constellation.
For more details, see the ActiveFacts project page at
http://dataconstellation.com/ActiveFacts
--
Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design
Walter Mitty
"noyb" <no....@please.net> wrote in message
news:MNgvm.29468$944....@newsfe09.iad...
> The RM is a self-contained model, and as such, can circumscribe
> the identity of a tuple, and it requires specifying a means to
> identify every tuple.
>
Let's not conflate the identity of a tuple with the identity of the entity
that an item of data in the tuple pertains to.
noyb
I'm not. But O-O programmers treat their objects much as we
do "natural world" objects; vis they don't concern themselves
with theory, only with pragmatic results.
You failed to comment on the fact that a tuple which has more
than one instantiation (location) is still *made to behave* as
though it was the same object (by being confined within ACID rules).
That supports your original assertion (identity derives from state
only) against those who claimed that location is also part of state.
You also failed to comment on the pointers I gave to my project,
which is a substantial and so-far effective attempt at getting us
out of our Vietnam, by uniting the best of object and relational
approaches under fact orientation. Please read carefully before
dropping any more of the pugnacious one-liners that this group is
known for.
Bob Badour
Clifford, you are full of shit.