 | |
#41
 
| |||||
| |||||
|
Re: Entity and Identity -
07-23-2009
, 06:31 PM
|
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. |
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!
Quote:
|
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. |
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.
Quote:
|
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. |
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.
Quote:
|
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. |
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
Quote:
|
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. |
(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.
#42
| |||||
| |||||
|
|
On Jul 22, 3:21 am, David BL <davi... (AT) iinet (DOT) net.au> wrote: On Jul 22, 12:57 pm, Brian <br... (AT) selzer-software (DOT) com> wrote: On Jul 21, 11:15 pm, David BL <davi... (AT) iinet (DOT) 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. |
of "field values". E.g. sometimes a state machine is defined by an
abstract set of states, a transition function etc.
Quote:
|
For there to be a state requires first that there be a state machine! |
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).
Quote:
|
It then follows that it can be possible for two distinct state machines to have equivalent, but not identical, states at a given time. |
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.
Quote:
|
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." |
"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).
Quote:
|
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). |
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.
#43
| ||||||
| ||||||
|
|
On Jul 23, 6:43 pm, Nilone <rea... (AT) gmail (DOT) 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. |
languages - more specifically, I'm opposing the class systems of
mainstream languages. I have no problem with state machines.
Quote:
|
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. |
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.
Quote:
|
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? |
many issues to make them worth the effort. Nearly all available OO
documentation leads one away from a clear understanding of the issues.
Quote:
|
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. |
existing working code, and can't be relied on for the purpose for
which they are intended.
Quote:
|
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 |
tool with wide application in programming. Current OO implementations
strive to be everything to everyone.
Quote:
|
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. |
understood and implemented in mainstream languages, were limited to
state machines.
#44
| |||||
| |||||
|
|
On Jul 23, 6:50 pm, Brian <br... (AT) selzer-software (DOT) com> wrote: |
Quote:
|
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. |
Quote:
|
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). |
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.'
Quote:
|
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). |
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."
Quote:
|
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 - |
#45
| |||
| |||
|
|
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. |
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
#46
| |||
| |||
|
|
[...] 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. [...] |
OO adds inheritance; is that where it breaks?
(BTW I agree with your criticism of inheritance.)
--
Reinier
#47
| |||
| |||
|
|
On Jul 23, 8:09 pm, David BL <davi... (AT) iinet (DOT) net.au> wrote: On Jul 23, 6:50 pm, Brian <br... (AT) selzer-software (DOT) 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? |
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?
Quote:
|
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.' |
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.
Quote:
|
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 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." |
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.
#48
| |||
| |||
|
|
Walter Mitty wrote: 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. And reinventing SQL...No thanks... Reinier |
#49
| |||
| |||
|
|
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? |
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.
Quote:
|
OO adds inheritance; is that where it breaks? (BTW I agree with your criticism of inheritance.) |
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.
#50
| |||
| |||
|
|
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. |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.