[openbeos] Re: BObjectList vs. TypedList
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 23 Jan 2003 15:48:35 +0100 CET
Hi Ingo,
> 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?
> 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.
Of course, someone should then work on a DiskProbe replacement sooner
or later :-))
Adios...
Axel.
Other related posts:
