Re: BTRIEVE::*
On Thu, Dec 18, 2003 at 03:49:07PM +0100, Steffen Goeldner wrote: I'm still open for namespace suggestions. The following list BTRIEVE::File BTRIEVE::ISAM::File BTRIEVE::ISAMFile BTRIEVE::IsamFile with descending preference comes into my mind. Assuming ISAM is implied by BTRIEVE there's no need to include that. A hint that it provides i/o might be good: BTRIEVE::FileIO otherwise BTRIEVE::File seems okay, if a little minimal. Tim.
Re: BTRIEVE::*
Steffen Goeldner wrote:
I understand your objections because each (but the first)
retrieval is based on a 'current record' - thus storing
that state in a separate iterator object may be a better
choice.
I rejected that! The documentation says:
Btrieve initializes the Position Block when your application
performs the Open operation, then references and updates it
during file operations. Therefore, your application must
specify the same Position Block on all subsequent Btrieve
operations for the file.
Thus a Position Block is like a file descriptor. The difference
is that it allows index-sequential (in addition to sequential)
access and bidirectional navigation.
The best I can do is to store it (and a few other state variables)
in a BTRIEVE::File object. Btrieve operations can then be called as
methods on that object, e.g.:
my $B = BTRIEVE::File-Open('TEST.BTR');
for ( $B-StepFirst; $B-IsOk; $B-StepNext ) {
print $B-{Data}
}
$B-{Key} = 123;
for ( $B-GetEqual; $B-IsOk; $B-GetPrevious ) {
print $B-{Data}
}
for ( $B-GetGreater; $B-IsOk; $B-StepPrevious ) {
print $B-{Data}
}
That's much easier to use than BTRIEVE::Native and still close
to the original API a Btrieve user is familar with.
I'm still open for namespace suggestions. The following list
BTRIEVE::File
BTRIEVE::ISAM::File
BTRIEVE::ISAMFile
BTRIEVE::IsamFile
with descending preference comes into my mind.
Steffen
Re: BTRIEVE::*
Whereas the top-level name was fixed to BTRIEVE, I still thought
about a convenient second-level name for the pure perl part.
Because it provides methods for common Btrieve operations and
these are operations on Btrieve files, I'd settle on
BTRIEVE::File
as module name. A typical usage scenario is
$f = BTRIEVE::File-Open('test.btr');
...
$f-GetEqual;
...
$f-GetNext;
...
$f-Close;
Steffen
Re: BTRIEVE::*
Tim Bunce wrote: Close() I can follow, And Open(), I hope ;-) but what are GetEqual and GetNext doing on a 'file' object? These are examples of 'Data Retrieval Operations' (my primary interest!), which return a record from the file. Step*() are physical operations, i.e. StepNext() is similar to perl's READLINE(). Get*() are key based operations. After setting some information about the key you can loop through the file similar to Step*() but in key order. I understand your objections because each (but the first) retrieval is based on a 'current record' - thus storing that state in a separate iterator object may be a better choice. Got a url to some docs? http://www.pervasive.com/library/prog_api/BtrIntro.html Steffen
Re: BTRIEVE::*
On 12/5/2003 1:05 PM, Tim Bunce wrote: Are you volunteering? Since I opened my big mouth, I guess I am. :o Now what exactly was I volunteering for again? Tim. On Thu, Dec 04, 2003 at 07:39:04PM -0500, Randy W. Sims wrote: On 12/4/2003 3:50 PM, Tim Bunce wrote: On Thu, Dec 04, 2003 at 11:42:07AM +0100, Steffen Goeldner wrote: Randy W. Sims wrote: Maybe DBMS::BTrieve::??? That looks good! But that's a new namespace. The horse has well and truly bolted on the db module namespace issue. They're all over the place. I think reusing an existing namespace is better than creating yet another one. I don't know (or can't remember) how the BTRIEVE::SAVE module got into the module list, but since it is that's the right place for new BTrieve modules. Tim. I missed that namespace. In fact, browsing http://www.cpan.org/modules/by-module/ I notice that things are /really/ getting out of hand. Maybe we need some CPAN police, volunteers for each of the domains listed at http://www.cpan.org/modules/by-category/, that must explicitly authorize new modules in that domain. Then we can have a Great CPAN Migration effort to herd some of the strays into the proper namespace. If there was just an easy procedure for migrating packages without the compatibility concerns... Randy. -- A little learning is a dang'rous thing; Drink deep, or taste not the Pierian spring; There shallow draughts intoxicate the brain; And drinking largely sobers us again. - Alexander Pope
Re: BTRIEVE::*
Tim Bunce wrote: I don't know (or can't remember) how the BTRIEVE::SAVE module got into the module list, but since it is that's the right place for new BTrieve modules. O.k., I settle on BTRIEVE::Native for the XS part. It'll implement BTRIEVE::Native::Call() which reads like there wasn't any doubt ;-) Steffen
Re: BTRIEVE::*
On 12/4/2003 3:50 PM, Tim Bunce wrote: On Thu, Dec 04, 2003 at 11:42:07AM +0100, Steffen Goeldner wrote: Randy W. Sims wrote: Maybe DBMS::BTrieve::??? That looks good! But that's a new namespace. The horse has well and truly bolted on the db module namespace issue. They're all over the place. I think reusing an existing namespace is better than creating yet another one. I don't know (or can't remember) how the BTRIEVE::SAVE module got into the module list, but since it is that's the right place for new BTrieve modules. Tim. I missed that namespace. In fact, browsing http://www.cpan.org/modules/by-module/ I notice that things are /really/ getting out of hand. Maybe we need some CPAN police, volunteers for each of the domains listed at http://www.cpan.org/modules/by-category/, that must explicitly authorize new modules in that domain. Then we can have a Great CPAN Migration effort to herd some of the strays into the proper namespace. If there was just an easy procedure for migrating packages without the compatibility concerns... Randy.
BTRIEVE::*
Hi, I'm about to release two modules: BTRIEVE::XS BTRIEVE::API The first, BTRIEVE::XS, is a simple XS wrapper module for Btrieve's single function API. I.e., you can call Btrieve's C function BTRCALL() in perl as BTRIEVE::XS::Call(). The second, BTRIEVE::API, provides methods for common Btrieve operations (on top of BTRIEVE::XS): Open StepFirst StepLast StepNext StepPrevious GetFirst GetLast GetEqual GetGreater GetNext GetPrevious Close Are these namespaces ok? Steffen
Re: BTRIEVE::*
On Wed, Dec 03, 2003 at 05:12:07PM +0100, Steffen Goeldner wrote: Hi, I'm about to release two modules: BTRIEVE::XS BTRIEVE::API The first, BTRIEVE::XS, is a simple XS wrapper module for Btrieve's single function API. I.e., you can call Btrieve's C function BTRCALL() in perl as BTRIEVE::XS::Call(). Are these namespaces ok? IT STRIKE ME THAT ALL UPPER CASE DOESN'T SEEM VERY perl LIKE. Also, does it need to be at the top level? What is Btrieve? Could your module sensibly live one level down, even if it means creating a new top level for it? Nicholas Clark
Re: BTRIEVE::*
On 12/3/2003 11:12 AM, Steffen Goeldner wrote: Hi, I'm about to release two modules: BTRIEVE::XS BTRIEVE::API The first, BTRIEVE::XS, is a simple XS wrapper module for Btrieve's single function API. I.e., you can call Btrieve's C function BTRCALL() in perl as BTRIEVE::XS::Call(). The second, BTRIEVE::API, provides methods for common Btrieve operations (on top of BTRIEVE::XS): I agree with Nicholas, about putting it in another namespace. Maybe DBMS::BTrieve::??? Also the names shouldn't really reflect the implementation, so XS is out. And every module has an API. I don't see any reason why this all couldn't be in a single module (with an XS part and a perl part), and name it something like DBMS::BTrieve::Direct to indicate that it communicates directly with BTrieve and doesn't use DBD or ODBC, etc. Regards, Randy.
