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: johnzabroski on 7 Mar 2010 21:24 On Mar 5, 11:38 pm, S Perryman <a...(a)a.net> wrote: > johnzabro...(a)gmail.com wrote: > > 2. Petri nets are inherently non-deterministic. > > Petri nets are deterministic. > Otherwise you cannot have "firing" . > > The order of arrival of tokens on places, is what is non-deterministic. > > Regards, > Steven Perryman Steven, That is exactly what I meant. Thank you for driving home the idea.
From: Dmitry A. Kazakov on 8 Mar 2010 02:50 On Sun, 07 Mar 2010 17:27:58 -0500, Daniel T. wrote: > The canonical example of object oriented design is the Observer pattern. > Think about the pattern and ask yourself, what is the postcondition of > Observer's update() method? Once you think about it for a bit, you will > realize that the only postcondition to the method is that it returns in > a finite amount of time. That's it, and that's all there can be. The logical fallacy of this reasoning is that pattern is not a [part of a] program. As such it cannot have pre- and postconditions. Pattern is a meta-program, much like templates are. Only when instantiated (applied to a concrete case) it becomes a proper program. Each *concrete* Update has pre- and postconditions, these include at least the invariant of the observer. Further, all Update (now considering observer a class) share certain common parts of their pre- and postconditions, which ensure that all observers get notified. These might be difficult to formulate, but semantically they certainly here. When you signal an event, the postcondition is a conjunction of the postonditions of the Updates of all observers in the queue. Note preconditions will appear too. You need to express a lot of semantics here: 1. Each Update is fired once 2. No Update is fired twice 3. For a sequence of events, Updates are called in the order of the events etc. P.S. About finite amount of time. This cannot be a postcondition for two reasons: 1. Time constraint is a non-functional requirement => does not belong here. 2. It is a halting problem, so it makes little sense to use it anyway, even if we ignored the position 1. 3. In an asynchronous scheme the event source (the publisher) does not wait for the subscribers. It only releases them. This scheme is frequently used in RT systems and OSes in order to prevent priority inversion problems. Example: OS design, a driver first catches the interrupt, but the actual I/O handling is postponed for processing on a lower priority level. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Nilone on 8 Mar 2010 04:30 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. The actor model of Hewitt et al. is the theoretical model for event- driven object-oriented systems.
From: S Perryman on 8 Mar 2010 06:48 Daniel T. 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.) Nonsense. The post-condition is an *observable consequence/effect* of the function. And more specifically, a *statement of correctness* . Your "caller" : 1. *expects* the function to *behave correctly* , however that correctness may be verified. 2. is a *potential observer* of the outcome, however that outcome may be observed. If said outcome is not of interest to the "caller" , then tis irrelevant (and effectively may as well not exist) . Just to prove this : C = "caller" , F = "function" var R : REAL ; R = sin(30) ; Has F behaved correctly as per Cs' needs ?? Yes. sin(30) = 0.5 . Does C require anything else of F ?? No. F produced the correct result. Does C care, or even know, that F has the following post-condition : RESULT IN [-1,1] No. Because that outcome has no bearing on the fact that sin(30) = 0.5 . OTOH, F satisfied the post-condition because F stated it *would* . And for no other reason (being "forced" to etc) . And F has no interest in who is *observing* whether F did what it stated it would. Contrast the above to the following : var R : REAL -1.0 .. 1.0 ; var x : REAL ; x = 30 ; R = sin(x) ; // do something with R ... Now C *does care* about the post-condition. Because C has constructed a premise based on the truth of the post-condition. Regards, Steven Perryman
From: S Perryman on 8 Mar 2010 06:59
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. 2. What you call "duck typing" is actually *structural equivalence* . Structural equivalence is an orthogonal concept to strong/weak typing (several FP langs are strongly-typed and support structural equivalence) . Regards, Steven Perryman |