On Tue, Aug 29, 2000 at 04:24:36PM -0400, Stephen P. Potter wrote:
> Deprecated, superseded, obsolete, whatever... it all comes down to the same
> thing. There is a better way to do it.
Says you. I say otherwise. Offer both ways, this ain't Python.
> | tie %hash, 'AnyDBM_File', 'somefile', O_RDWR|O_CREAT, 0644;
>
> Don't try to explain that to a newbie. Let them learn it on their own.
> There are plenty of examples that just use
>
> tie %hash, 'AnyDBM_File', 'somefile', 1, 0
>
> that never explain what 1, 0 are for.
I have no idea what 1 and 0 do in that context, and I can't find it
explained anywhere. Its mentioned once in the AnyDBM_File man page.
ETOOMAGICAL!
Furthermore, it doesn't work.
$ perl -MAnyDBM_File -le 'tie %hash, "AnyDBM_File", "test.foo", 1, 0 or die $!'
No such file or directory at -e line 1.
O_WRONLY is 1 (on my system). I believe what's being attempted is to
open an existing DBM file for writing only. Of course, this will not
create a new file. It also makes assumptions about the value of Fcntl
constants. Very Bad.
Feeding 0 as the mode... not sure what that's going to do. Since most
*DBM_File modules simply feed the mode directly to their dbm_open()
functions (or equivalent) its behavior will be dependent on the DBM
library.
$ perl -wle 'dbmopen %hash, "test.foo", 0664 or die $!'
works just fine with no mystery and regardless of the existance of test.foo.
> I also seem to remember an RFC to
> make "tie %blah 'DB'" automatically do a "use DB".
That would be nice.
> | Now, this doesn't mean dbmopen() has to remain as a builtin. It could
> | be written as a pure Perl wrapper around tie() and AnyDBM_File. But
> | keep it somewhere. Its useful and its not bothering anyone.
>
> Keep it in a DB.pm module, if you want. There's no need to keep it in the
> core binary. I'd much rather teach people
All the arguments about removing the high falutin math functions (RFC
155) apply here, so I'll just sum up:
- Its about 100 lines of core code. Removing it won't make a difference.
- dbmopen() is compartimentalized. Its not bothering any other part
of Perl (unlike something like, say, threads or indirect object syntax)
- dbmopen() is very stable (although there are a few things I'd like to
see changed. RFC forthcoming.) Removing it would be much more work
than just leaving it in.
- There are issues of being able to share memory used by core modules.
As I said before, this is all nickel and dime stuff. None of it is
going to make a real difference. The heart of the matter is should
Perl's core functions remain monolithic, or should they be split up
into modules? And if they should be split, can we do it just as
efficiently as if they were monolithic? Discuss that. Once its been
decided, all these other tertiary issues will fall into place.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
But why? It's such a well designed cesspool of C++ code. Why wouldn't
you want to hack mozilla?
-- Ziggy
