Darren New schrieb:

>> That C part of ACID would be covered by the contract-oriented paradigm 
>> I think.
> 
> Well... to some extent, yes. Contract-oriented tells you the 
> relationships with individual objects. The C of ACID tells you the 
> relationships between objects. But they're similar concepts, yes.
> 
> The contract-oriented paradigm won't tell me if I change the Customer 
> class and it breaks the Order class.

In contract-oriented programming, how could you possibly break the Order 
class by a change in the Customer class? All you could possibly do is 
/violate the contract/ of the Order class.

As far as that is concerned, such a violation /could/ be detected by 
static code analysis (within limits regarding the complexity of the 
pre-/postconditions), or by running the application in debug mode with 
pre-/postcondition checks enabled (within limits regarding test coverage).

I don't see where the C in ACID could be verified any differently.


>>> I can't imagine changing a queue to a stack without needing to 
>>> rewrite a fair amount of the code using that structure.
>>
>> That direction may indeed be problematic, but changing from a stack to 
>> a double-ended queue shouldn't be a problem, as a stack is just a 
>> special case of a deque that provides no access to the "head" of the 
>> queue.
> 
> True, but then why would you do that if you aren't going to be 
> dequeueing stuff at the other end? :-)

Maybe the underlying type needs to be changed to allow doing just that, 
to implement some change request (or fix a design flaw).


>> That it's not so easy with the STL is a problem of C++, not OO 
>> languages in general. And even with the STL it would be a piece of 
>> cake if you had chosen to use a typedef (which you could interpret as 
>> a kind of "identity inheritance") in the first place instead of 
>> hard-coding the type name everywhere.
> 
> Right. I mean, that's a trivial kind of thing. You have the same problem 
> with names in Java as you do in C++.  If you code your functions to all 
> take arguments of type stack, changing to a dequeue is going to require 
> tracking all those down, just like if you did it with STL.

In Java, if you'd be smart you wouldn't declare function arguments as of 
a certain /class/ type, but of a certain /interface/ type. You can then 
easily "upgrade" to a more powerful type without changing any existing 
code (except for the actual container object creation).

In other OO programming languages, you could do the same using the type 
names of abstract base classes instead of whatever actual implementation 
is used.

If you did your homework properly, most OO languages will allow you to 
pull off the stunt even without recompiling most of the code.


> The point I was making is that there are lots of paradigms

I presume this sentence was left incomplete? (Otherwise: Erm... yes, 
there are indeed lots of paradigms :-))

> Yes. But they're not inherited from each other, and they're not 
> necessarily dynamically dispatched. All you're saying is that you can do 
> things similar to OO with templates.  I.e., yes, the *design* is OO, but 
> the implementation need not be, so you're making my point for me that 
> you can have generic containers without OO.

But my primary point was that the OO /paradigm/ was highly influential 
in the creation of such type libraries - and that a non-OO approach 
doesn't get you there, unless you somehow "emulate" OO behavior.

In the case of the STL, the library in a sense uses a "static OO" model: 
The implementing classes are /designed/ to be interchangeable without 
code change (to the extent that they implement the same "concept"); they 
are /designed/ to use the same function names and parameters for the 
common functionality. The only thing they lack is a language that allows 
them to carry this flexibility over to run-time.

>> Note that data encapsulation /is/ an OO trait. 
> 
> It's a trait of a lot of languages. It's not the definitive trait of OO.

This discussion seems familiar to me. I'd say it is /the/ most important 
trait of OO.


>> And are you really sure they don't use any OO portions behind the scenes?
> 
> They might, but that's not the point.

Oh yes, it part of the point I'm making.


> Does the STL's dequeue inherit from the STL's stack, or vice versa?

No, but they both "inherit" from the same "concepts".


>> A library using an OO design does not necessarily imply that you can 
>> subclass it, or any of its components.
> 
> Right. But then it's just a library. Subclassing and inheritance is one 
> of the primary defining features of (class-based) OO. Otherwise, it's 
> just a nice way of passing a pointer around, and you might as well do it 
> the same way stdio.h does.  (stdio is a library with an OO design, yes?)

 From an object's caller's point of view, OO support in programming 
languages /is/ "just a nice way of passing a pointer around".

 From an object implementation's point of view, OO support in 
programming languages /is/ typically nothing more than syntactic sugar 
to automatically generate implementation details such as virtual method 
tables, and (in the case of class-based OO) provide the compiler with 
hints about type compatibility.

And, as you say yourself, subclassing and inheritance is one of the 
primary defining features of /class-based/ OO. Given that there is 
non-class-based OO, obviously subclassing and inheritance /cannot/ be 
the primary defining features of OO in general.

Post a reply to this message