2

In an Apple paper about Object Oriented Programming, it depicts objects sending messages to each other. So Appliance can send a message to Valve, saying requesting for water, and the Valve object can then send a message to the Appliance, for "giving the water".

(to send a message is actually calling the method of the other object)

So I wonder, won't this cause subtle infinite loop in some way that even the programmer did not anticipate? For example, one is if we program two objects, each one of them pulling each other by gravity, so one is sending to the other object, that there is a "pull" force, and the other object's method got called, and in turn sends a message to the first object, and they will go into an infinite loop. So if the computer program only has 1 process or 1 thread, it will simply go into an infinite loop, and never run anything else in that program (even if the two object finally collide together, they still continue to pull each other). How does this programming paradigm work in reality to prevent this?

Update: this is the Apple paper: http://developer.apple.com/library/mac/documentation/cocoa/conceptual/OOP_ObjC/OOP_ObjC.pdf

Update: for all the people who just look at this obvious example and say "You are wrong! Programs should be finite, blah blah blah", well, what I am aiming at is, what if there are hundreds or thousands of objects, and they send each other messages, and when getting a message, they might in turn send other messages to other objects. Then, how can you be sure there can't be infinite loop and the program cannot go any further.

On the other hand, for people who said, "a program must be finite", well, what about a simple GUI program? It has the event loop, and it is an infinite loop, running UNTIL the user explicitly asks the program to stop. And what about a program that keep on looking for prime numbers? It can keep looking (with BigNum such as in Ruby so that there can be any number of digits for an integer), so the program is just written to keep on running, and write the next larger prime number into the hard disk (or write to hard disk once every million time it find greater prime number -- so it find 1 million prime number and write that 1 millionth to the hard drive and then keep on looking for the next million prime numbers and write the 2 millionth number to hard drive (write only 1 number, not 1 million of them). Well, for a computer with 12GB or RAM and 2TB of hard drive, maybe you can say it can take 20 years for the program to exceed the capability of the computer, when hard disk is full or when the 12GB of RAM cannot fit all the variables (it might be billion of years that an integer cannot fit in 1GB of RAM), but as far as the program is concerned, it just keep running, unless the memory manager cannot allocate another BigNum, or the hard drive is full, that the exception is raised and the program is forced to stop, but the program is written to run indefinitely. So not all programs HAS TO BE written to be finite.

nonopolarity
  • 146,324
  • 131
  • 460
  • 740
  • In reality, gravity is a field effect not an exchange of messages. – Richard Schneider Mar 30 '11 at 09:11
  • 1
    i thought there was mentioning of graviton that gravity is actually by sending messages between 2 objects. and in reality, if you pull two tennis balls side by side, they do pull each other, so can't you consider one sending the other a "pulling force"? (even though the force is extremely small) – nonopolarity Mar 30 '11 at 09:12
  • Your Appliance and Valve example outlines asynchronous message passing where water is not delivered immediately and only when it becomes available. This is desired in many scenarios, i.e. in multithreaded GUI programming, but for great majority of cases water should be just a response (a return value) for request sent by Appliance. After all you can always throw an exception if there is no water. In the end "passing a message" is no different than just calling a function and as such return value feels the most natural approach in this example. – Michał Niedźwiedzki Mar 30 '11 at 09:42
  • Well, the reality is actually a loop that never ends. If a program eventually stops then it models the reality imperfectly :) – Alsk Mar 30 '11 at 10:10
  • The first principle of dynamics states: A body will preserve it state of motion or rest until another force(usually external) changes this state. So it is only natural that a loop occurs. Automation is a loop and we need it all the time t. It is up to us to decide when the "force" must change the state of motion or rest upon a process. If you can not anticipate it then it is a poor design. The main property of an algorithm is Finiteness, if it is not finite it is not an algorithm, if one can make it finite, one is not a programmer, one is a coder. No one can stop you from doing things wrong. – Catalin Marin Mar 30 '11 at 10:19
  • I am citing this as a simple example, so of course it is easy to say: oh no, it is wrong! But what I am aiming to look at is, what if there are hundreds or thousands of objects in your system, if you send messages this way, won't there be subtle ways of creating infinite loops without the programmer knowing it? – nonopolarity Mar 31 '11 at 01:28
  • @Catalin Don't you know that the force exists regardless of the motion, collision, or whatever it is, the force exists and is always there. Besides, you sound like you want to be superior to say you are a programmer, not a coder. – nonopolarity Mar 31 '11 at 15:51

3 Answers3

3

Why should Appliance request for water repeatedly?
Why should Valve bombard Appliance saying that water is being provided?

In theory - it's likely to create infinite loop, but in practice - it comes down to proper modeling of Your objects.

Appliance should send ICanHasWater message only once, wait for response, receive water or receive an answer that water cannot be provided, or will be in future when Applicance might want to try requesting water once again.

that's why I went into the 2 objects and gravity example instead.

Infinite loop of calculation of gravity effects between objects would happen only if You would trigger this calculation on calculation.

I think that common approach is to introduce Time concept and calculate gravitation for particular TimeFrame and then move on to next one for next round of calculation. That way - Your World would have control over thread between TimeFrames and Your application might do something more useful than endless calculations of gravity effects.

Arnis Lapsa
  • 45,880
  • 29
  • 115
  • 195
  • that's why I went into the 2 objects and gravity example instead. – nonopolarity Mar 30 '11 at 09:18
  • I think if you introduce `Time`, then it is somewhat like a main function, simply calling each object's method repeatedly, instead of letting the objects interact with themselves... I think I wrote most of my OOP programs using the "time" method. But what about the "letting objects interact with themselves" method -- it is a valid method, isn't it? – nonopolarity Mar 30 '11 at 09:43
  • @動靜能量 it is "letting objects interact with themselves", but only in given time frame. You know - real world would go into endless recursion w/o time concept too. :) – Arnis Lapsa Mar 30 '11 at 09:51
  • @動靜能量 and w/ time concept, You can resolve "which ball pulls other one first" issue. You can describe how next frame will look like w/o messing up current one. – Arnis Lapsa Mar 30 '11 at 10:08
2

Without OOP it is as easy to create infinite loops unintentionally, using imperative programming languages or functional programming maybe. Thus I cannot see what is special about OOP in this case.

If you think of your objects as actors sending each other messages, it's not necessarily wrong to go into an infinite loop. GUI toolkits work this way. Dependend on the programming language used this is made obvious by a call to toolKit.mainLoop()or the like.

I think that even your example of modelling gravity by objects pulling at each other is not wrong per se. You have to ensure that something is happening as a result to the message (i.e. the object being accelerated and moving a little) and you will get a rough discretization of the underlying formulae. You want to check for collision nevertheless to make your model more complete :-)

Using this model requires some level of concurrency in your program to ensure that messages are processed in proper order.

mkluwe
  • 3,823
  • 2
  • 28
  • 45
  • whether there is collision or not, the gravitation pull still exists. before they collide, at, and after they collide, the pull is no more, no less. – nonopolarity Mar 31 '11 at 01:29
  • Yes, of course. I just wanted to indicate that collision will make the task more interesting: Your object could stick together, bump or break as a result from collsion. But you're right, this has almost nothing to do with your question. – mkluwe Mar 31 '11 at 19:49
  • actually, the pull is more, or less, depending on the distance between them, but the idea is, no matter what, the pull exists, **always**. – nonopolarity Apr 01 '11 at 05:27
1

In real life implementations there's no infinite loop, there's infinite indirect recursion instead - A() calls B(), B() calls C() and on some branch C() calls A() again. In your example if Appliance sends GetWater, Valve sends HeresYourWaterSir inmmediately and Appliance's handler of HeresYouWaterSir for whatever reason sends GetWater again - infinite indirect recursion will begin.

So yes, you're right, in some cases problems can happen. The OOP paradigm itself doesn't protect against that - it's up to the developer.

sharptooth
  • 167,383
  • 100
  • 513
  • 979
  • since you seem wise, do you know any answer to this one? http://stackoverflow.com/questions/5484593/what-might-be-a-good-object-oriented-programming-book-that-can-give-a-good-solid – nonopolarity Apr 01 '11 at 05:46
  • @動靜能量: I can't advise anything good - I've seen several books, but they were mediocre, I wouldn't recommend them. – sharptooth Apr 01 '11 at 05:52
  • you might want to read that paper... beginning page 11... i haven't read anything like that... quite new way of thinking – nonopolarity Apr 01 '11 at 06:34
  • @動靜能量: I looked through - especially pages 15 and 16 - and there's nothing revolutional. They just say that calling a member function of an object can be perceived as sending a message to that object. Well, yes, that a way of thinking about that. – sharptooth Apr 01 '11 at 06:40