Re: Object Oriented Template Library ( OOTL ) version 0.1
Posted: Nov 26, 2004 12:48 PM
> > >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.
> the OOTL you can express concepts properly using
I'll look more into the documentation.
> > Moreover, this means you can use types that have not
> > 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
> > 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.
> > In fact, before STL, there were several OO container-
> > algorithm libraries, but when STL came, it demonstrated
> > that this could be done without inheritance from a
> > base or interface, and thus be usable with built-in
> > as well.
> > I think instead the way forward is to have better
> > 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.