>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 01:33 PM 8/9/00 -0400, Chaim Frenkel wrote:
>> I don't think it will be a half million objects.
>>
>> Let's take stat (and all the other long list returns). The underlying
>> implementation object could be a packed structure psuedohash. (Think
>> DSECT.) Then the only op would be the packed structure pseudohash
>> lookup. Which would be done at compile time. (Fallbacks to the hash
>> lookup if really generic.)
DS> stat makes some sense. (local|gm)time makes some sense. The socket
DS> functions make some sense. The message and shared memory functions
DS> make some sense. Basically most of the 'advanced' functions make
DS> some sense. That's the problem--they all make some sense, which
DS> is a lot of code to get right for the .0 release.
I'm not quite in favor of the proposal, but I'm not sure it is so
extensive. (As I see it, all of the internals are being rewritten.
So the work has to be done.)
This isn't an N <-> N problem. This is more limited. The perl -> op
level, would be the access method. The advance funcs, would only
have to get the mapping correct.
Actually, by rationalizing the return "object" you might be making
the internal coder's life easier.
What am I missing?
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
