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: Nilone on 8 Mar 2010 12:48 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.
From: Nilone on 8 Mar 2010 13:06 On Mar 8, 12:41 pm, r...(a)zedat.fu-berlin.de (Stefan Ram) wrote: > "Daniel T." <danie...(a)earthlink.net> writes: > >Here is a simple quote that might help. "In OO programs, objects tend to > >tell other objects what happened, instead of telling them what to do." > > I consider the following binary message of Smalltalk > > 3 - 4 > > , it is explained as > > Receiver = 3 > Selector = #- > Argument = 4 > "Subtract 4 from 3" > > in > > http://www.smalltalk-resources.com/Smalltalk-Getting-the-Message.html If I was designing a scalar data type like numbers in an actor system like Smalltalk, I would design Number to be a singleton object with methods to instantiate value objects from and to other types like strings, as well as all the desired numeric operators. The value objects created by this Number object wouldn't have any publicly visible methods or attributes whatsoever.
From: johnzabroski on 8 Mar 2010 13:25 On Mar 8, 1:06 pm, Nilone <rea...(a)gmail.com> wrote: > On Mar 8, 12:41 pm, r...(a)zedat.fu-berlin.de (Stefan Ram) wrote: > > > > > "Daniel T." <danie...(a)earthlink.net> writes: > > >Here is a simple quote that might help. "In OO programs, objects tend to > > >tell other objects what happened, instead of telling them what to do." > > > I consider the following binary message of Smalltalk > > > 3 - 4 > > > , it is explained as > > > Receiver = 3 > > Selector = #- > > Argument = 4 > > "Subtract 4 from 3" > > > in > > >http://www.smalltalk-resources.com/Smalltalk-Getting-the-Message.html > > If I was designing a scalar data type like numbers in an actor system > like Smalltalk, I would design Number to be a singleton object with > methods to instantiate value objects from and to other types like > strings, as well as all the desired numeric operators. The value > objects created by this Number object wouldn't have any publicly > visible methods or attributes whatsoever. This doesn't make much sense. William Cook already thought out in the late '80s and early '90s how to do common data types in Smalltalk, and this is most definitely not the solution. Sounds like you should also read Cook's OOPSLA '09 paper that I linked for Ed.
From: Nilone on 8 Mar 2010 15:43 On Mar 8, 8:25 pm, "johnzabro...(a)gmail.com" <johnzabro...(a)gmail.com> wrote: > On Mar 8, 1:06 pm, Nilone <rea...(a)gmail.com> wrote: > > > > > On Mar 8, 12:41 pm, r...(a)zedat.fu-berlin.de (Stefan Ram) wrote: > > > > "Daniel T." <danie...(a)earthlink.net> writes: > > > >Here is a simple quote that might help. "In OO programs, objects tend to > > > >tell other objects what happened, instead of telling them what to do.." > > > > I consider the following binary message of Smalltalk > > > > 3 - 4 > > > > , it is explained as > > > > Receiver = 3 > > > Selector = #- > > > Argument = 4 > > > "Subtract 4 from 3" > > > > in > > > >http://www.smalltalk-resources.com/Smalltalk-Getting-the-Message.html > > > If I was designing a scalar data type like numbers in an actor system > > like Smalltalk, I would design Number to be a singleton object with > > methods to instantiate value objects from and to other types like > > strings, as well as all the desired numeric operators. The value > > objects created by this Number object wouldn't have any publicly > > visible methods or attributes whatsoever. > > This doesn't make much sense. William Cook already thought out in the > late '80s and early '90s how to do common data types in Smalltalk, and > this is most definitely not the solution. Sounds like you should also > read Cook's OOPSLA '09 paper that I linked for Ed. Thanks for the reference. I've seen it before, but a few more readings can only help. Note that my intention was to reproduce the traditional integer data type since I'm not yet comfortable with other approaches for such simple scalars. However, that paper doesn't explain the correct way to design an integer class, only an integer set class. I checked some other papers where he described recursive types, but each such example was based on the assumption of existing number classes or types. It sounds like you are familiar with the correct technique. I would appreciate it if you could explain (simply), please?
From: S Perryman on 8 Mar 2010 16:31
johnzabroski(a)gmail.com wrote: > Just to clarify, a static type system with *static type checking and* ... > strong typing enforces > strong typing guarantees at compile-time where as a dynamic type > system with strong typing system with strong typing and *dynamic type checking* > enforces strong typing guarantees at run-time. > Of course, most languages use in-between notions of these > extreme concepts. > And it is not always the case that either is always > superior to the other. For example, to enforce contracts between > callers and callees, you would likely need to use some run-time > checking Proof systems (assuming the premises in the correctness artifacts are decidable, and the proof system is capable of making the required deductions) . Proof systems tend to operate statically. > OR have the caller's return context statically handle the > callee's DoesNotUnderstand message at compile-time. Apart from something like meta-typing manipulation, there is no concept of "DoesNotUnderstand message" in strongly-typed prog langs. > Notice how the > information required to statically check a strong typing system at > compile-time requires more information than at run-time A type error that occurs at point P in a program requires the *same* information to deduce the error. The only difference is that for the knowledge base K constituting type information for a program, K is constructed : - in its *entirety* for static analysis - *incrementally* for dynamic analysis as the program executes Regards, Steven Perryman |