[futurebasic] Linked-list fn library

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : August 2004 : Group Archive : Group : All Groups

From: Jay Reeve <jayreeve@...>
Date: Mon, 30 Aug 2004 17:33:50 -0500
On Monday, August 30, 2004, at 11:05  AM, tedd wrote:

> I just believe that we can develop an internal storage methodology 
> which can attend to itself and can hide the complexity of a linked 
> list r/b b-tree from the user.
>
> Is that any clearer?  And, if you, or anyone else, has/sees any 
> problems with this, please discuss.

tedd,

Yes, that's much clearer. My first thought, confirmed by Scott's 
subsequent posts, is that this functionality probably already exists. 
Haven't you written those functions for all of your linked-list work? 
Wouldn't that be the place to start for the "Standard Library" you're 
suggesting?

It might be fun for me to take Richard P's functions, or yours, and see 
if I can  further optimize or make them more generically useful, but I 
frankly have no idea (as yet) how one goes about balancing a tree. This 
is your field of expertise (or one of them). Why don't you give it a 
shot?

My earlier comment about needing to know the user's organizational 
objective is probably the biggest hurdle to creating a really usable 
generic library. Even after we know what field to sort, do we use an 
ASCII sort, a numeric sort, a length sort, a case-insensitive sort, 
etc.? We could limit ourselves to strings, like INDEX$ does, but I 
think that severely limits the utility.

Okay--my brain just kicked in. Hang on.

If I'm starting to get a glimmer of what you're proposing, maybe it 
could work this way--Any field of a record array could have one or more 
keys attached to it. Each key would comprise a separate array of links, 
which would be updated anytime there was a change in the data array. If 
there were keys attached to more than one field, or if there were more 
than one key attached to a field, all would be updated in the 
background with each change in the data.

The library functions might include something like these:

local fn DBNew(dbRecType)
' Creates a new dynamic DB of type dbRecType . Returns dbID, or zero if 
error.

local fn DBClose(dbID )
' Removes the DB.

local fn DBAdd(dbID, @recPtr)
' Appends the data at recPtr to dbID, updating all keys. Returns DB 
item num, or -1 if error.

local fn DBDelete(dbID, itemNum)
' Marks the item as deleted  and removes it from all keys. (Won't be 
physically deleted until db is compacted.)

local fn DBCompact(dbID )
' Compacts the array to  reclaim space from any deleted records, and any
' unused records, updating all attached keys in the process. Returns the
' number of records in the DB.

local fn DBWrite(fileNum, dbID, writeKeys)
' Writes the array to the open file fileNum, appending all keys if 
writeKeys
' is non-zero. Returns Syserr.

local fn DBRead(fileNum, dbID)
' Reads the array from open file fileNum, including attached keys if 
they
' were saved. Returns Syserr.

local fn DBMerge(dbID1,dbID2,allowDups)
' Merges dbID2 into dbID1 (of the same record type),  removing duplicate
' records iff allowDups == _false. Deletes dbID2. Only the keys from 
dbID1
' are retained and updated. Returns number of records retained, or -1 
if error.

local fn DBInfo(dbID, @validCount, @deleteCount, @availCount,

local fn KeyNew(dbID, fld, _sortType)
' Builds a b-tree link array for the indicated field of dbID. Returns 
keyID which is unique to this DB,
' so any reference to this keyID implies the DB to which it is attached.
' One field may have more than one key attached (for different kinds of 
sorts).

' Possible sortTypes might include:
'	_sortASCII
'	_sortVal
'	_sortDateTime
'	_sortStringLen
'	_sortInteger
'	_sortReal
'	_sortBool
'
' To these could be added:
'	_sortAscend
'	_sortDescend
'	_sortUnique

' To the string sorts could be added:
'	_sortCaseSens
'	_sortNonSens

local fn KeyRemove(keyID)
' Discards the key,  releasing the memory used by the key array.

local fn KeyFind(keyID, @matchPtr)
' Returns the DB item number of an item == the data at @matchPtr.
' If no item is equal,  returns negative number of first item > data at 
@matchPtr.

local fn KeyFirst(keyID)
' Returns DB item number of first sorted item  in keyID.

local fn KeyLast(keyID)
' Returns DB item number of last sorted item  in keyID.

local fn KeyNext(keyID)
' Returns the DB item number of the next item in keyID, or -1 if no 
more items.

local fn KeyPrev(keyID)
' Returns the DB item number of the preceding item in keyID, or -1 if 
no more items.
============

Confession time. I adapted a lot of this from Prograph,  a language I 
tried some  years ago, which had a pretty easy-to-use integrated DB 
system employing keys.

As you can see, the task is daunting but manageable. I have some other 
things to do before I can start any real coding on it, but I have some 
further ideas for structure if you are interested in giving it a start. 
I'm eager to hear your thoughts.

  e-e
  =J= a  y
   "

--
To unsubscribe, send ANY message to: futurebasic-unsubscribe@...