the gulf between bog-standard and actually good OO?
in [OOP]
|
Prev: Call for Paper The International Journal of Computer Science (IJCS)
Next: CFP with Extended Deadline of Mar. 21, 2010: The 2010 International Conference on Computer Graphics and Virtual Reality (CGVR'10), USA, July 2010
From: Dmitry A. Kazakov on 8 Mar 2010 17:04 On Mon, 08 Mar 2010 21:31:09 +0000, S Perryman wrote: > Apart from something like meta-typing manipulation, there is no concept > of "DoesNotUnderstand message" in strongly-typed prog langs. Or to put it slightly different, there is no type errors in strongly typed languages. So even if DoesNotUnderstand is present, then it does not indicate a type error. The type is OK, it does have the method Foo. It is just so that Foo is contracted to propagate DoesNotUnderstand. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: raould on 8 Mar 2010 17:52 > How often do you read books? i have seemingly next to zero time (the old excuse) so i pretty much only get to read things online, or when i'm waiting for the red traffic light to turn green. so my reading time is not so great these days. :-( hence my attempts to glean understanding from online resources cf. Lahman's tutorials. sincerely.
From: Daniel T. on 8 Mar 2010 20:21 Nilone <reaanb(a)gmail.com> wrote: > On Mar 8, 3:13�pm, "Daniel T." <danie...(a)earthlink.net> wrote: > > Nilone <rea...(a)gmail.com> wrote: > > > On Mar 7, 7:15 pm, "Daniel T." <danie...(a)earthlink.net> wrote: > > > > > > > A procedural function has a specific postcondition that it must > > > > fulfill in order to be considered correct, the caller is > > > > guaranteed that the postcondition will hold true and can operate > > > > under that assumption. In a very real sense, the caller is using > > > > the function to *force* the postcondition to become true. The > > > > caller is in control in this situation. Putting such a function > > > > in a class doesn't change this basic characteristic > > > > (container.insert(x) is not an OO function, but a procedural one > > > > precisely for this reason.) A vast majority of code in any > > > > program will consist of such procedures. > > > > > > > > An OO function's only postcondition guarantee is that it will > > > > return in a finite amount of time. > > > > > > > > If "car.gasPedalPressed()" were an OO function, then there would > > > > be *no* guarantee that the car would begin accelerating when the > > > > function was called. If the car started accelerating, it would > > > > be because the *car* wanted to, not because the caller wanted it > > > > to. > > > > > > > > The ant analogy comes in here. One ant never tells another ant > > > > what to do, ants tell others what they have been doing, and each > > > > ant takes the information that comes in and decides what to do > > > > based on the information. > > > > > > You're describing event-driven programming, which can be > > > contrasted with imperative and declarative programming. > > > �Object-oriented modelling is orthogonal to all three. > > > > Please continue. How is Object-Oriented code different from > > non-Object-Oriented code? > > I sense shaky ground, but let me step forth boldly. ;) > > Object-oriented code would be code which describe the interaction > between objects in a system. The interactions between objects depend > on your point of view, though. Imperative OO programming describe > objects inspecting and manipulating each other. Declarative OO > programming describe relations between objects and attributes. Event- > driven OO programming describe objects reacting to each other's > signals. > > Non-object-oriented code would be the imperative, declarative and > event-driven programming languages before OOP, i.e. based on scalar > values and built-in data types. Two things immediately come to mind. The C programming language has "objects" (the C standard defines "object") and many functions in C "describe the interaction between objects in" the program, while at the same time it is "a language before OOP." Care to try again? One program is written in an OO style, while another program (written in the same language and performing the same job,) is not. (This kind of of stuff is talked about all the time using Java as an example.) What is the difference between the two programs? It's not an easy question to answer...
From: Nilone on 9 Mar 2010 02:45 On Mar 9, 3:21 am, "Daniel T." <danie...(a)earthlink.net> wrote: > Nilone <rea...(a)gmail.com> wrote: > > On Mar 8, 3:13 pm, "Daniel T." <danie...(a)earthlink.net> wrote: > > > Nilone <rea...(a)gmail.com> wrote: > > > > On Mar 7, 7:15 pm, "Daniel T." <danie...(a)earthlink.net> wrote: > > > > > > A procedural function has a specific postcondition that it must > > > > > fulfill in order to be considered correct, the caller is > > > > > guaranteed that the postcondition will hold true and can operate > > > > > under that assumption. In a very real sense, the caller is using > > > > > the function to *force* the postcondition to become true. The > > > > > caller is in control in this situation. Putting such a function > > > > > in a class doesn't change this basic characteristic > > > > > (container.insert(x) is not an OO function, but a procedural one > > > > > precisely for this reason.) A vast majority of code in any > > > > > program will consist of such procedures. > > > > > > An OO function's only postcondition guarantee is that it will > > > > > return in a finite amount of time. > > > > > > If "car.gasPedalPressed()" were an OO function, then there would > > > > > be *no* guarantee that the car would begin accelerating when the > > > > > function was called. If the car started accelerating, it would > > > > > be because the *car* wanted to, not because the caller wanted it > > > > > to. > > > > > > The ant analogy comes in here. One ant never tells another ant > > > > > what to do, ants tell others what they have been doing, and each > > > > > ant takes the information that comes in and decides what to do > > > > > based on the information. > > > > > You're describing event-driven programming, which can be > > > > contrasted with imperative and declarative programming. > > > > Object-oriented modelling is orthogonal to all three. > > > > Please continue. How is Object-Oriented code different from > > > non-Object-Oriented code? > > > I sense shaky ground, but let me step forth boldly. ;) > > > Object-oriented code would be code which describe the interaction > > between objects in a system. The interactions between objects depend > > on your point of view, though. Imperative OO programming describe > > objects inspecting and manipulating each other. Declarative OO > > programming describe relations between objects and attributes. Event- > > driven OO programming describe objects reacting to each other's > > signals. > > > Non-object-oriented code would be the imperative, declarative and > > event-driven programming languages before OOP, i.e. based on scalar > > values and built-in data types. > > Two things immediately come to mind. The C programming language has > "objects" (the C standard defines "object") and many functions in C > "describe the interaction between objects in" the program, while at the > same time it is "a language before OOP." > > Care to try again? From what I saw, "objects" in the C standard are used for memory storage. OK, I'll try again. Objects are the domain of discourse of programming language statements. > > One program is written in an OO style, while another > program (written in the same language and performing the same job,) is > not. (This kind of of stuff is talked about all the time using Java as > an example.) What is the difference between the two programs? > > It's not an easy question to answer... This description is much too vague to comment on. If you give examples or references, I'll comment on them. Event-driven programming is a well-known architecture with features such as inversion of control (e.g. "In OO you don't tell the object "we are in the state where you will do X," you tell the object "we are in this state"; what the object does with that information is its business.") and unbounded nondeterminism (e.g. "An OO function's only postcondition guarantee is that it will return in a finite amount of time."). Object-oriented modeling is a separate concept. As you point out, even the C standard has them. It's the difference between what we can talk about and how we can talk about those things.
From: S Perryman on 8 Mar 2010 22:53
Stefan Ram wrote: > "johnzabroski(a)gmail.com" <johnzabroski(a)gmail.com> writes: >>This has to do with the difference between objects and ADTs as data >>abstraction techniques. > I would either compare > (OOP-)objects with abstract objects (ADT-objects) or > (OOP-)types with AD-types > but not > (OOP-)objects with AD-types. > (OOP-)objects have (OOP-)types and > (ADT-)objects have (AD-)types. > In CLU (Liskov, Zilles; 1974), an object of an ADT is called > an �abstract object�. My definitions have always been : 1. ADTs. 2. Object-based = ADTs + "self reference" 3. OOP (classes) = Object-based + inheritance The reason I defined the above is because #3 (Simula) came before #1, and I want to indicate the fact that the concepts found in ADTs are applicable to OOP too, regardless of the emergence in time of the concepts. >>Objects represent *one* interface, > They fun starts when objects have /multiple/ interfaces. > (Depends on how you define and count interfaces, you can > always mentally count a combination of several interfaces to > be a single interface.) With type substitutability and structural equivalence, a type with N properties has 2^N - 1 interfaces. I haven't included the 'empty' interface here, although it conceptually does exist (and may be of use to something) . Regards, Steven Perryman |