[openbeos] Re: BObjectList vs. TypedList

On Thu, 23 Jan 2003, Axel =?iso-8859-1?q?D=F6rfler ?= wrote:

> > I believe, this has not been discussed yet, but will soon be of
> > relevance for the SK team; therefore I bring it up. Most of you
> > certainly know the nice class BObjectList, a type save and extended
> > BList subclass. It is part of the OpenTracker source and, due to its
> > usefullness, already found its way into our repository (headers/
> > private
> > /shared/ObjectList.h).
>
> We might also just move it into os/support/, shouldn't we?

If we intend to declare it a public API, we should do that. Then we should
make sure, that the usual binary compatibility precautions are taken
(for _PointerList_).

> > Now there exist two facts, that may be less well known:
> > 1) There exists a very similar class, TypedList, which has been used
> > by
> > Be internally. I believe, that TypedList has been copied and renamed
> > to
> > BObjectList, when the Tracker source has been released. At this time
> > they may differ a bit.
> >
> > 2) Both classes are not directly derived from BList, but from
> > _PointerList_ and PointerList respectively. Neither of these classes
> > has an OpenBeOS implementation yet (hint, hint ;-).
> >
> > Why bother, you might ask, when TypedList was used internally only,
> > then we can just drop it?! Well, unfortunately its usage `leaked'
> > into
> > private but visible API, the Device (Map) API, the SK team is about
> > to
> > tackle. It is used in the OpenTracker (as well as in mountvolume (and
> > should also be used in DriveSetup, BTW)) and thus we have to
> > replicate
> > it.
> >
> > So the question at hand is: Do we want to implement both list
> > classes?
> > Personally I would vote for dropping TypedList. The consequence is
> > obviously, that we would also drop binary and source compatibility
> > with
> > respect to the Device API. But since the only applications using that
> > private API are either open source (OpenTracker) or have to be
> > replicated by us anyway (mountvolume), that wouldn't actually harm.
>
> Since you obviously are planning on other changes as well, we could
> just completely drop binary and source compatibility and resolve all
> issues with this API.

Er, well, yes. :-) This idea came a bit later though. :-)

> Of course, someone should then work on a DiskProbe replacement sooner
> or later :-))

DriveSetup? Well, at least an almost empty implementation already exists
in the tree. BTW, since DriveSetup uses the DriveSetup add-ons directly
(not through the Device API), and we are not going to replicate this
interface, this has to be done anyway.

CU, Ingo

Other related posts: