Process v. Object?

OK, I've been thinking about the pragmatic difference between a process and an object.

I'm told that a process has a beginning, it does something, then dies.

An object on the other hand lies around until it is asked to do something.

But pragmatically couldn't one look at the object as a sort of daemon process? Is there some fundamental low level difference in its implementation in assembly code or something? Or is that really how its implemented?

I'm just all sixes and sevens over this minor issue...

Processes and objects are situated on two entirely different levels. I'd first like to point out that, to even begin this discussion, we need to know what exactly you mean by a process and an object, as their meanings vary based on what you're talking about (and who you're talking to...). MS, for example, simply defines a process as a running application ("an executing instance of an application"). An object, in object-oriented programming, is defined as an instance of a class.

In any case:

Quote:

---

An object on the other hand lies around until it is asked to do something.

---

This might be more semantics than anything else, but I don't think you can accuse an object of doing anything; an object is (or is not); what comes closest to "doing" something when it comes to an object is that an object manages its own state (which can hardly be called "doing" something). What does do something is a method (an object's "behavior"). In that context, I think the discussion would have more merit when you ask for the difference between a "method" and a "process", rather than between the difference between an "object" and a "process" (as that difference, to me at least, is comletely obvious as they are so totally different).

Well, I would consider a process to be a running program.

An object is the compiled program code just sitting there?

I was thinking with regards to "Procedural programming" and "Object Oriented Programming"...I was told by a coder far wiser than I that a process is basically characterized by having a beginning, it does something, and then it ends.

An object is characterized by having a state that is manipulated by its methods.

But with such definitions, couldn't one argue that a daemon process could be an object if it is programmed correctly? An object also has a beginning, a series of changes of state, and then it finalizes.

Quote:

---

This might be more semantics than anything else, but I don't think you can accuse an object of doing anything; an object is (or is not); what comes closest to "doing" something when it comes to an object is that an object manages its own state (which can hardly be called "doing" something). What does do something is a method (an object's "behavior"). In that context, I think the discussion would have more merit when you ask for the difference between a "method" and a "process", rather than between the difference between an "object" and a "process" (as that difference, to me at least, is comletely obvious as they are so totally different).

---

Hmm...this is possibly the case, but I was thinking more with regard of the actual handling of instantiating an object rather than the philosophical aspects behind it.

Suppose we were naively looking at a daemon thread running, it's manipulated to do something, and then it returns to daemonize. Is there a way to differentiate this from an object doing a method, if we choose to look at the code at (say) assembly code?

I'm sure this is a stupid question that has a clear cut answer, but it's been on my mind for a while...so I really do appreciate the replies, they have gotten me thinking about aspects of this matter I hadn't previously thought of :)

Well, I would still argue that a process is a running program and that an object is the compiled or assembled set of instructions that make up the program.

So a process would have at least one object, and an object will have one or more processes.

When I look at a process I think in terms of actions and achievements. When I look at an object I think in terms of methods or techniques.

Sort of the process is what you do, and the object is how you do it?

Nihil,

Your definitions don't work anymore, though, when we're talking object-oriented languages. I'm with you as far as "a process is a running program" goes; your definition of an object does not conform with the way an object is used in object-oriented programming, though. A process does not need to have at least one object (in object-oriented "speak": you do not need to instantiate classes, i.e. you do need to "create" objects) ; furthermore, an object does not need one or more processes (in object-oriented "speak", objects do not have "processes"; they have methods).

In object-oriented languages, an object is an instantiation of a class (for example: "John's 2004 Ford Mustang" is an object - an instantiation of a class (the class "car", for example)). An object can have methods or techniques (called "methods" in OO), but an object is not a method or technique...

Ahem, I noob to disturb here.

Well, from my point of view, in the OO world too the word hold thier meanings as they do in the real world. Such as both 'human' and 'apple' object. The objects have properties. It may or may not have methods. Even though an object without any method would not be a true object, an object is just like properties in the sense 'how it looks'. On the other side, the method or process is the way things are done.

So Object is just a set of things that would not do anything or would not hold any importance untill it is attached to a process or a method while running. The properties of the object(s) show up when the methods accosiated with them come to action. They are so different.