|
Re: Object Oriented Template Library ( OOTL ) version 0.1
|
Posted: Nov 26, 2004 9:48 AM
|
|
> > >However, why the desperate need for object orientation > > for >container classes? Or algorithms/tools? Sure, I > > suppose a >list IS-A collection, and an array IS-A > > collection, but do >those relationships really need > > formalising? > > > > In fact, they _are_ formalised, as you know: as generic > > concepts (such as the "Container" concept). > > Can that really be considered formalised? There is > absolutely nothing to enforce or verify concepts.
It depends on what you mean by "formalised". What I meant with it is that there are defined requirements for them. However, as you say, there's no direct support for concepts in C++ (although there are papers/proposals for this).
There are, however, ways to get some of the benefits of concept support, such as Boost Concept Check Library, or the CTL library I mentioned in another posting. Used together with boost::enable_if, you can actually overload on concepts, as well.
It seems the BIL library may do something similar, as you say, so I'll look into it.
> Using > the OOTL you can express concepts properly using > interfaces.
I'll look more into the documentation.
> > Moreover, this means you can use types that have not > been > > made to be used with STL, as long as they satisfy the > > concept requirements. > > The implication seems to be that there is some kind of > arbitrary restrictions on the OOTL that do no exist.
No, like I said in the posting, I had only looked a little at the docs, so my comparison above was mostly based on how traditional OO-versions of container- and algorithm-libraries work (such as in Java), where components need to inherit from interfaces and/or a universal base class. Judging from other postings in this thread, it seems I wasn't alone in making this connection.
However, as I understand, your library is different in this respect, which motivates me to take a better look at it. I guess my posting was kind of an "is this just another OO-framework, or different (i.e. something worth looking into more)?" question. :)
> > This means there's no dependency of > > a common base class or interface, something you have > with > > an OO approach. > > Not neccessarily. The OOTL uses BIL interfaces types which > are compatible with any object providing matching > signatures, much like an STL concept. There is no need for > any preparation in an object.
Interesting.
> > In fact, before STL, there were several OO container- > and > > algorithm libraries, but when STL came, it demonstrated > > that this could be done without inheritance from a > common > > base or interface, and thus be usable with built-in > types, > > as well. > > > > I think instead the way forward is to have better > support > > for generic concepts in C++. > > So you are clearly implying that I am going backwards.
No, there was a "precondition" that apparently wasn't that clear, and I'm sorry for that. The "precondition" was: _if_ your library worked the same way traditional OO-libraries work. There's a reason STL was adopted, and the other pre-STL ones faded away. However, I understand your library is different.
> It is hard to not be annoyed by such statements.
Please don't take this as personal offence; none was meant. Like I said, my posting was not at least an attempt to see if this was worth looking more into. Your own blog and docs, with its emphasis on "OO" and "problems with non-OO things", was also I guess something I felt could need challenging, or at least a clarifying of what you were criticising about STL, or everything non-OO in general.
> I would recommend taking a look at the documentation before you > jump to conclusions.
I will. As you see from the above, I had not come to any conclusion at the point of posting, simply because I knew too little about it. Jumping to conclusions is something I try to avoid. However, you might have taken my "provocative" posting (which was partly motivated by your own mentioned criticism of STL, etc.) as I having made up my mind. It was not so.
Regards,
Terje
|
|