clipka wrote:
> Dream on :-)

Well, sure, that's the whole thread, isn't it? :-)

> Automatic code generation from tools has been the subject of wishful 
> thinking for decades. Yes, CASE tools do exist. But where are they used, 
> and how powerful are they really?

I think part of the problem is that you can't go back. You generate the code 
from the CASE tool, and then when you modify the code, you can't generate 
the CASE tool files from it.

> I've seen such a tool only once in real life: It was used to document 
> state machines and generate code for them. But even there, too often 
> people would just try to make it generate the state machine they wanted, 
> instead of actually documenting it. And more often than not, the actual 
> "meat" code would contain additional hidden state variables.

Sure. The trick is to make it *easier* to write the documentation first.

Like, take the whole TDD thing going on. What if your top-level module was a 
"unit", and inside that unit you had your implementation and your test 
cases. Then you couldn't write code without a test case. A bit B&D, but 
could you make it easier to write test cases than not?

>> The problem with writing code documentation is that it doesn't help 
>> the coder. It only helps the people who come after. So it's seen as a 
>> waste unless the coder understands the business reason for it.
> 
> Exactly. But this will not happen unless management understands the 
> business reason for it in the first place, and makes sure the coder has 
> enough time to carefully plan, document and test his work.

Yes. And heaven help you if you're writing open source code, where there's 
no business need to make it usable to anyone else. :-)

> 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.

>> 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? :-)

> 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.

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

>> C++ seems to do pretty well, and its not using any OO for the STL.  
> 
> Oh, sure it does! For instance, the class behind the vector::iterator 
> type derives from the class behind vector::const_iterator, which in turn 
> derives from some obscure class _Ranit - to name just the very first 
> example I chanced upon.

It doesn't *have* to, tho. There's nothing in the paradigm that makes that 
so, unlike in OO coding. The iterators may inherit, but the other things 
don't need to. There's no dynamic dispatch involved, so it's not OO.

> And the /design/ of the STL is heavily object-oriented at any rate. For 
> instance, the documentation refers to both "deque<T,Alloc>" and 
> "vector<T,Alloc>" as /models/ (think "implementation") of the /concepts/ 
> (think "abstract classes" or "interfaces") "Random access container" and 
> "Back insertion sequence" (with "deque" also being a model of "Front 
> insertion sequence").

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.

> 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.

> And are you really sure 
> they don't use any OO portions behind the scenes?

They might, but that's not the point.

> You were obviously 
> mistaken regarding STL.

STL is a specification, not an implementation. Everyone is free to implement 
it differently.

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

> 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?)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message