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: Daniel T. on 8 Mar 2010 08:08 ram(a)zedat.fu-berlin.de (Stefan Ram) wrote: > "Daniel T." <daniel_t(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 > > . I strongly expect the receiver to treat the selector #- as > a kind of �command� for the subtract operation, and would > consider everything else as a misbehaviour. > > The objects must have an /interface specification/ (contract). > The programmer reads this and writes his client code accordingly. > The object must fulfil its specification, > otherwise it is malfunctioning. > > I do not see how to get rid of such tell-to-do type of > programming. It even is recommended by such rules as > �tell, don't ask.�. I don't think it would be a good idea to get rid of "such tell-to-do" type of programming. It is an important part of every system. OO isn't for everything. > Sometimes, �tell what's happend� /is/ used, but this is the > same as in procedural programming: > > reportTemperature( t ); > > . We have just measured the temperature t and now report > it to a procedure whose contract allows it to do anything. > Such a contract might be a contract of a procedure in > procedural programming and is not necessarily connected > specifically with object-oriented programming. OO style programming doesn't require a particular language, or a particular feature of a language. OO can be done in almost any language. All that is required is the ability to defer the algorithm choice until runtime.
From: Daniel T. on 8 Mar 2010 08:13 Nilone <reaanb(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?
From: johnzabroski on 8 Mar 2010 11:47 On Mar 8, 6:59 am, S Perryman <a...(a)a.net> wrote: > Stefan Ram wrote: > > Ok, languages without static types (as languages with »duck typing«) > > do not have written interface specifications as part of the language. > > Still, their programmers use such types, as already can be seen in > > the saying »If it looks like a duck, quacks like a duck and walks > > like a duck - then it is probably a duck.«, which talks about the > > type (interface) »duck«. > > 1. You are talking about *weakly-typed* prog langs (ones where the types > of input and output parameters are not known) , as opposed to > *strongly-typed* prog langs. > > Static type envs is an orthogonal concept. Just to clarify, a static type system with strong typing enforces strong typing guarantees at compile-time, where as a dynamic type system with strong typing 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, OR have the caller's return context statically handle the callee's DoesNotUnderstand message at compile-time. Notice how the information required to statically check a strong typing system at compile-time requires more information than at run-time, but also facilitates reasoning about code by adding more definitions about what will happen at run-time.
From: johnzabroski on 8 Mar 2010 11:52 On Mar 7, 1:47 pm, Ed <iamfrac...(a)hotmail.com> wrote: > On 7 mar, 18:15, "Daniel T." <danie...(a)earthlink.net> wrote: > > > > > An OO function's only postcondition guarantee is that it will return in > > a finite amount of time. > > Fascinating. > > Daniel, do you have any links to further reading on this point (my > googling's skills have failed me)? > > Thanks, > > Ed. Ed, This has to do with the difference between objects and ADTs as data abstraction techniques. Objects represent *one* interface, and so they have the flexibility of implementation hiding, including "lying". It is actually this flexibility to "lie" that also gives objects their flexbility to serve as a uniform security model (e.g., implementing the object capability security model in ocaps-secured languages like The E Programming Language described in Mark Miller's Robust Composition Ph.D. Thesis). See William Cook's recent OOPSLA '09 paper On understanding data abstraction, revisited. http://lambda-the-ultimate.org/node/3668
From: johnzabroski on 8 Mar 2010 11:59
On Mar 8, 11:52 am, "johnzabro...(a)gmail.com" <johnzabro...(a)gmail.com> wrote: > On Mar 7, 1:47 pm, Ed <iamfrac...(a)hotmail.com> wrote: > > > On 7 mar, 18:15, "Daniel T." <danie...(a)earthlink.net> wrote: > > > > An OO function's only postcondition guarantee is that it will return in > > > a finite amount of time. > > > Fascinating. > > > Daniel, do you have any links to further reading on this point (my > > googling's skills have failed me)? > > > Thanks, > > > Ed. > > Ed, > > This has to do with the difference between objects and ADTs as data > abstraction techniques. > > Objects represent *one* interface, and so they have the flexibility of > implementation hiding, including "lying". It is actually this > flexibility to "lie" that also gives objects their flexbility to serve > as a uniform security model (e.g., implementing the object capability > security model in ocaps-secured languages like The E Programming > Language described in Mark Miller's Robust Composition Ph.D. Thesis). > > See William Cook's recent OOPSLA '09 paper On understanding data > abstraction, revisited.http://lambda-the-ultimate.org/node/3668 Let me amend that. The caller should expect the callee to return in a finite amount of time. However, due to the law of excluded middle, it is entirely possible for the callee to never return. As post-conditions really belong to the caller, the only thing the caller can enforce is the knowledge that an object can lie. Therefore, if the caller cannot wait forever, then it must enforce a finite time expectation. So the post-condition is not something that the callee object enforces (which Daniel's post(s) sort of seemed to suggest). The responsibility for enforcing the post-condition belongs to the return context. |