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: Ed on 9 Mar 2010 10:19 On 8 mar, 17:52, "johnzabro...(a)gmail.com" <johnzabro...(a)gmail.com> wrote: > > See William Cook's recent OOPSLA '09 paper On understanding data > abstraction, revisited.http://lambda-the-ultimate.org/node/3668 Thank you, sir. Ed.
From: Daniel T. on 9 Mar 2010 10:21 Nilone <reaanb(a)gmail.com> wrote: > On Mar 9, 3:21 am, "Daniel T." <danie...(a)earthlink.net> wrote: > > > 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. You know what it is when you see it, but you can't tell me what you are looking for? Robert Martin once said that OO means using of jump tables. Do you agree, or at least think he was close? > 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. Separate how?
From: johnzabroski on 9 Mar 2010 10:35 On Mar 8, 5:04 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > 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. Kazakovhttp://www.dmitry-kazakov.de Exactly. Things considered to be type errors (reduction to the "wrong" type) are really just the compiler saying the program shouldn't be compiled, because its behavior is undefined at least insofar as the compiler cares. Steven, You simply just have to model the fact that objects can reject or refuse to act on messages. I would argue that this is more flexible than structured exception handling with checked exceptions, and matches procedural data abstraction better than structured exception handling. Most programmers use structured exception handling in a way that is intended to communicate to the caller that they violated some contract, rather than to communicate that the subsystem failed unexpectedly somehow. It's a big shift in thinking to rethink such problems.
From: johnzabroski on 9 Mar 2010 10:52 On Mar 8, 4:31 pm, S Perryman <a...(a)a.net> wrote: > johnzabro...(a)gmail.com wrote: > > > 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 I think you simply misunderstood my point. If a type error occurs at run-time, and there is no specified strategy for dealing with that type error, then run-time behavior *after* point P is undefined. A type system does not have to be complete, and can allow for undefined semantics. The compiler is allowed to emit whatever the hell kind of code it wants when a type error occurs, including code that makes demons fly out your nose [1]. A type system does not have to be complete, and can allow for undefined semantics. However, if we change the language such that we force callers to handle the possibility of DoesNotUnderstand, then the receiving object can still dynamically interpret the message; the type system just doesn't say what the effect of that message will be, because it can't, so instead it simply models a monolithic DoesNotUnderstand message. Then there will be *no type error*, and the compiler cannot make nasal demons. The key here is how the sender and receiver interact. An example would be Representational State Transfer (REST), where in HTTP the response codes for DoesNotUnderstand are less monolithic. The receiving object can still send back a "lying" response code, but that is a separate matter -- it changes how you think about what your type system is actually proving. More generally, when specifying a system, specifications can be (1) defined (2) implementation defined (3) unspecified (4) undefined [1] http://catb.org/jargon/html/N/nasal-demons.html
From: johnzabroski on 9 Mar 2010 10:55
On Mar 8, 5:54 pm, r...(a)zedat.fu-berlin.de (Stefan Ram) wrote: > "johnzabro...(a)gmail.com" <johnzabro...(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«. > > >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.) Your message is so confusing and therefore likely wrong. Unfortuantely, I do not know how to correct it. Sorry. I have a feeling you are referring to the Law of Demeter and Robert Cecil Martin's Interface Segregation Principle, which is *completely* unrelated to this discussion. Martin's use of the word interface is completely different from the one being used in this discussion. Ah, English language! |