Quote:The underlying implementation may be, but the end user usage is somewhat more abstract.

No it isn't.

Quote:The methodologies are quite distinct.

No they aren't.

Quote:The most common langauge, C++, enforces no such restrictions [on how operations are organised].

It certainly does. It has destructive assignments; this means it must have restrictions on the organization of operations. We see this in, for example:

int a = 0, b = 1;a = 2; // 1b = a; // 2a = b; // 3

These operations *must* be performed in an order that gives the right results:

123: a == 2, b == 2: ok132: a == 1, b == 1: not ok213: a == 2, b == 2: ok231: a == 2, b == 0: not ok312: a == 2, b == 2: ok321: a == 2, b == 1: not ok

When you have destructive assignment you are not free to arbitrarily reorder.

Quote:Because OOP was developed to minimise the potential failures that such a linear structure can have.

But it doesn't remove those "potential failures". It's not clear that it even reduces them.

char a[99999],*p=a;int main(int c,char**V){char*v=c>0?1[V]:(char*)V;if(c>=0)for(;*v&&93!=*v;){62==*v&&++p||60==*v&&--p||43==*v&&++*p||45==*v&&--*p||44==*v&&(*p=getchar())||46==*v&&putchar(*p)||91==*v&&(*p&&main(0,(char**)(--v+2))||(v=(char*)main(-1,(char**)++v)-1));++v;}else for(c=1;c;c+=(91==*v)-(93==*v),++v);return(int)v;}  /*** drpizza@battleaxe.net ***/

Quote:Yes they are.

No, they really aren't. This is why you can have both OO imperative languages (e.g. C++, Java, etc.) and OO declarative languages (e.g. o'caml). The former tend to greatly resemble procedural programming; where they vary is for the most part in their syntax (they make function calls look a bit different).

The code in C++ or Java etc. is still procedural; it breaks problems up into modules and subroutines (it might call them "packages" instead of "modules" and "methods" instead of "subroutines" but it amounts to the same thing) with scoped variables.

What makes these languages "OO"? Well, they allow one to define a record type (encapsulating some state) and a number of subroutines to manipulate that state. They'll call these things "classes" and "methods", but they're not doing anything that procedural code doesn't. What they might do that's a little different is make the subroutines subordinates to the records. But even then, the differences are just syntactic; they merely mean one writes "foo.bar(baz)" instead of "bar(foo, baz)". This is not really a great difference; there's little in practical terms between, for example:

// "OO"fstream myfstream("path/to/file", ios_base::in | ios_base::out | ios_base::binary);myfstream.write(arr, arrSize);myfstream.close();

and

// "non-OO"FILE* myfilestar = fopen("path/to/file", "rb+");fwrite(arr, 1, arrSize, myfilestar);fclose(myfilestar);

In procedural and imperative OO alike, programs are broken down into lexically scoped sequentially evaluated subroutines. "OO" and "procedural" are orthogonal concepts; "OO"--if it means anything at all--makes state manipulation subordinate to state. But that's the extent of it. It implies nothing greater about a program.

Quote:Order isn't the be all and end all or organisation. Assignment is a special case: always a method, but other operations can usually be factored any way the programmer would like.

The compiler can't in general reorder anything in an imperative language. Order of evaluation *matters*. Sequential evaluation is *important*.

Quote:As said, it minimises these failures.

Not demonstrated in practice; OO software is not cheaper to produce or less buggy than mere "procedural" code.

Quote:Constructors and destructors are a blessing, and have made many a design feasable in C++.

Constructors and destructors do not make any design feasible that would not otherwise be feasible. They're a convenient shorthand, but no more.

char a[99999],*p=a;int main(int c,char**V){char*v=c>0?1[V]:(char*)V;if(c>=0)for(;*v&&93!=*v;){62==*v&&++p||60==*v&&--p||43==*v&&++*p||45==*v&&--*p||44==*v&&(*p=getchar())||46==*v&&putchar(*p)||91==*v&&(*p&&main(0,(char**)(--v+2))||(v=(char*)main(-1,(char**)++v)-1));++v;}else for(c=1;c;c+=(91==*v)-(93==*v),++v);return(int)v;}  /*** drpizza@battleaxe.net ***/